Portability Blog - Comments

Danny: transparent_union

nospam@example.com (Danny) — Mon, 26 Jul 2010 15:18:34 +0200

Yeah, that's true enough. Notice that the blog article was written in 2007, when the documented (and hence recommended) way was the same as in my examples.

Maybe that fact is relevant in itself. If you have code from before 2008, check GCC documentation for changes

Davi: transparent_union

nospam@example.com (Davi) — Mon, 26 Jul 2010 13:04:06 +0200

If you take a finer look at the bug report, they say it's supported but not the recommended way. By not using the recommend way one is subject to bugs such as this.

Anyway, the bug report is relevant for those tripping upon this, or to others looking into why transparent_union is ifdef for the PPC

Danny: transparent_union

nospam@example.com (Danny) — Mon, 26 Jul 2010 09:43:27 +0200

This is not the case. The restriction means the attribute can't be inside the braces. It can be anywhere after the closing brace.

The gcc test case referred from the bug report you quoted puts it last as well:
http://gcc.gnu.org/viewcvs/trunk/gcc/testsuite/g%2B%2B.dg/ext/attrib32.C?view=markup&pathrev=142019

GCC documentation now contains examples that have the attribute before the opening brace:
http://gcc.gnu.org/onlinedocs/gcc/Type-Attributes.html

The version of this page that was current when this blog article was written still has the attribute last:
http://web.archive.org/web/20071031085950/http://gcc.gnu.org/onlinedocs/gcc/Type-Attributes.html

Davi: transparent_union

nospam@example.com (Davi) — Mon, 26 Jul 2010 00:33:52 +0200

That's because of the tag is in the wrong place. Quoting from the GCC manual:

"An attribute specifier list may appear as part of a struct, union or enum specifier. It may go either immediately after the struct, union or enum keyword, or after the closing brace. The former syntax is preferred."

Also, see:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36410

Danny: Bad register name "dil" (or "sil")

nospam@example.com (Danny) — Wed, 04 Nov 2009 12:51:09 +0100

You can find out if your compiler toolchain knows about %dil by comparing the output from 32 bit and 64 bit builds, e.g with gcc:

32 bit:
$ echo 'main(){___asm___("mov %dil,%dil");}' | gcc -m32 -c -x c - -o /dev/null
/tmp/ccWDlW7T.s: Assembler messages:
/tmp/ccWDlW7T.s:13: Error: bad register name `%dil'

64 bit:
$ echo 'main(){___asm___("mov %dil,%dil");}' | gcc -m64 -c -x c - -o /dev/null

I don't think there ever was an x86_64 assembler that didn't know about this register, but it's possible that your compiler frontend doesn't pass a required argument to your assembler. It's also possible that the project you're building just assumes the compiler will build for x86_64 by default, which isn't necessarily the case, although I haven't seen Linux systems configured that way yet; it's more common on certain commercial UNIX platforms.

ryan: Bad register name "dil" (or "sil")

nospam@example.com (ryan) — Wed, 04 Nov 2009 02:07:06 +0100

Hmm....If what you are saying is true, how come I am getting the following message?

CC arch/x86_64/boot/printf.o
CC arch/x86_64/boot/string.o
CC arch/x86_64/boot/tty.o
CC arch/x86_64/boot/video.o
arch/i386/boot/boot.h: Assembler messages:
arch/i386/boot/boot.h:110: Error: bad register name `%dil'
make[2]: *** [arch/x86_64/boot/video.o] Error 1
make[1]: *** [bzImage] Error 2
make[1]: Leaving directory `/home/navyserver/MENG/blocktag-kernel-2.6.23'
make: *** [debian/stamp/build/kernel] Error 2
navyserver@navyserver-desktop:~/MENG/blocktag-kernel-2.6.23$ uname -m
x86_64

TheWitness: SO_SNDTIMEO and SO_RCVTIMEO

nospam@example.com (TheWitness) — Wed, 02 Sep 2009 14:27:24 +0200

Alarms, what a "hack". I do not want to have to control the behavior of inline code through a callback. Why can't the UNIX guys just properly adopt sockets?

Let me guess, they laid off all the developers years ago when they thought UNIX was "good enough". That's my guess.

TheWitness

Danny: SO_SNDTIMEO and SO_RCVTIMEO

nospam@example.com (Danny) — Wed, 22 Apr 2009 11:50:42 +0200

We don't, since the platform doesn't support socket timeouts. We use plain old alarm signals instead.

Antonio: SO_SNDTIMEO and SO_RCVTIMEO

nospam@example.com (Antonio) — Wed, 22 Apr 2009 11:13:09 +0200

I have been running through that exact problem with a porting to HP-UX 11iv3. My question is, how would you tackle the problem of setting socket timeouts in that platform (which aren't silently ignored)?

Daniel Fischer: socklen_t confusion

nospam@example.com (Daniel Fischer) — Sun, 29 Mar 2009 11:18:09 +0200

This may get you into trouble on HP-UX as per what I wrote in the article.

dm: socklen_t confusion

nospam@example.com (dm) — Wed, 08 Oct 2008 13:13:39 +0200

I use "socklen_t" instead of "int", like this:
...
socklen_t addrlen; /* arg for accept */
...
desc = accept(sock, (struct sockaddr *) &addr1, &addrlen);
...
and all work.