Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon.

Pages: 1-

libcrypt on ARM5

Name: Anonymous 2010-10-11 0:08

I'm trying to compile libcrypt on a SheevaPlug running Debian Squeeze, but it keeps giving me the following error:

invalid operands to binary != (have ‘va_list’ and ‘void *’)

is there any way to get this thing to compile without major hacking?

Name: Anonymous 2010-10-11 0:23

ARM5
Surely you mean ARMv5... right?

It sounds like you've already had your hands all over it. Try casting a spell.

Name: Anonymous 2010-10-11 0:25

libcrypt? what the fuck is wrong with you?  use OpenSSL and OpenSSH like a real man

Name: Anonymous 2010-10-11 0:26

>>2
yeah, ARMv5, little-endian, EABI

Name: Anonymous 2010-10-11 1:12

The libcrypt code is bad. Rewriting the test to check the first vararg instead would probably do the trick I guess. You might have to reorder the rest of the varag processing after doing that.

Post a section of the affected code maybe?

Name: Anonymous 2010-10-11 1:17

Whoever wrote that did it wrong. You should use provided functions for dealing with va_lists, not use regular operations.

Name: Anonymous 2010-10-11 10:50

Here's the entire function in question:

http://pastebin.com/2weHVvqi

Name: Anonymous 2010-10-11 11:37

that is some fugly code right there

Name: Anonymous 2010-10-11 16:33

>>7
That's worse than expected. Complain to the libcrypt guys and/or use something else.

Name: Anonymous 2010-10-11 19:12

>>9
Already done.  The bug derives from the fact that on ARM-eabi with gcc4.4, va_list is a struct.  I can't use something else right now, because I just need it as a dependency for compiling a Synchronet BBS.

Name: Anonymous 2010-10-11 19:29

>>10
Syncronet brings back memories. If you're determined to make it work and the libcrypt guys are no help you can fudge the test. It might even work just as well without the test, since it's a sanity check that probably bails hard. Note that if testing a va_list was really a practical thing to do it would be done in the various printf functions.

Name: Anonymous 2010-10-11 20:32

>>1
Yeah.  Delete the line,
REQUIRES_B( argPtr != NULL );
That line is incorrect.

Name: Anonymous 2010-10-12 2:58

>>11
I decided to avoid the whole clusterfuck of a program ported from DOS/Win32.  I actually got iBBS [url]http://sourceforge.net/projects/ibbs/[/url] working, and re-encoded all the ANSI art into UTF-8 so you don't need a goddamn cp437 terminal to see it.  It's all done in shell scripts, mostly bash and ksh.  Probably my favorite feature is you can use almost any console program as a "door" - including nethack or perhaps guile.

Name: Anonymous 2010-10-12 3:03

>>12
I did that, and it's compiling now.  Are you a wizard, or just a goofy snake with sound advice?

Name: Over 14 Posts 2010-10-12 5:17

This thread has over 14 replies.
You can't reply anymore.

Name: Anonymous 2010-10-12 5:24

>>15
test

Name: Anonymous 2010-10-12 8:34

>>14
It's pretty obvious if you've written a lot of C. That stands out as a sanity check and, if you know how va_lists are used, a pointless one at that.

Name: Anonymous 2010-10-12 13:02

>>17
I haven't written much of anything in C yet, but from what I've seen and done I like it a lot better than Java (language I started on in CS courses).  Python's also winning me over - not only can it do awesome things with AJAX, Qt, and Gtk, it can do them really quickly.  Of course, now Synchronet itself is making gcc cry, but with iBBS up and running that's not a big deal for me.

Name: Anonymous 2010-10-12 15:20

>>18
Well, you've just seen the very worst C has to offer: va_lists. Nobody with any sense ever uses them unless it has to do with a printf/variant implementation or wrapper.

Name: Anonymous 2010-10-12 18:28

>>19
There are a few other places they're used.  For example, in CPython they're used for packing/unpacking tuples.  They're not that bad, and they're very useful in some situations.  The only real problem they have is that the type checker can't verify that you read the same type out of a va_list as you put in, but you're writing C code so it's assumed that you're an adult.

Name: Anonymous 2010-10-13 10:24

>>19
What blows my mind is that the type of a va_list changes between implementations.  What knob-gobbling fuckmint decided that was a good idea?

Name: Anonymous 2010-10-13 10:51

>>21
Who cares? Just use the macros that are provided for handling them and stop trying to do weird shit.

Name: Anonymous 2010-10-13 10:54

>>21
AFAIK they all satisfy the spec (I haven't cared enough to check.) The problem is that people use them wrong (i.e. by depending on implementation specific behavior) and the spec is lacking for people who feel the need to make their code babysit the programmers. (There are supposedly legit needs for the kind of test seen here but I don't really know what they are, or how legitimate they really are.) C just tries to keep a low profile with respect to runtime overhead where ever possible. IMO, variadic functions are just not C's thing and that doesn't bother me.

Name: Anonymous 2010-10-13 19:04

>>23
Oh? And how else are people supposed to use them if the implementation behaves oddly? By not using them?

Name: Anonymous 2010-10-13 19:53

>>24
Seriously? If you use them according to the spec (esp.: avoiding any usage marked as "undefined behavior") then it will be completely portable and not "behave oddly" on any conforming implementation.

Name: Anonymous 2010-10-13 22:03

>>25
Only until you bump into one of the many non-conforming compilers.

Name: Anonymous 2010-10-13 23:36

>>26
Variadic functions are the least of your concerns if your compiler doesn't have a conforming preprocessor.

Name: Anonymous 2010-10-13 23:51

>>26
pretty sure gcc 4.4 is conformant

Name: Anonymous 2010-10-14 0:07

>>28
He probably thinks comparisons to va_lists are spec'd.

Name: Anonymous 2010-10-14 0:08

>>27,28
I'm speaking generally.

Name: Anonymous 2010-12-17 1:39

Erika once told me that Xarn is a bad boyfriend

Name: Anonymous 2011-02-03 6:48

Name: Anonymous 2011-02-18 12:58

check 'em
Don't change these.
Name: Email:
Entire Thread Thread List
All trademarks and copyrights on this site are owned by their respective parties. All comments and posts are the responsibility of their own posters.
- Tinychan + 2ch Mode -