Discussion:
The saga of signal.h
(too old to reply)
jacobnavia
2017-07-29 11:03:10 UTC
Permalink
Raw Message
Definitely, signal.h is a strange file.

/usr/include/signal.h

contains this definitions:

224 typedef uint32_t u_int8_t ;
225 typedef uint32_t u_int16_t ;
226 typedef uint32_t u_int32_t ;
227 typedef uint32_t u_int64_t ;

???

So, if you see a type called "u_int8_t" you should know is NOT an
integer with 8 bits but with 32!!!!!

What could be possibly the objective of that definition?

Mislead people into impossible to spot gotchas?

Gcc never ends to surprise me.

Do other linux distros have this definitions?
Manfred
2017-07-29 14:33:00 UTC
Permalink
Raw Message
Post by jacobnavia
Definitely, signal.h is a strange file.
/usr/include/signal.h
224 typedef uint32_t u_int8_t ;
225 typedef uint32_t u_int16_t ;
226 typedef uint32_t u_int32_t ;
227 typedef uint32_t u_int64_t ;
???
I don't have any of this in my /usr/include/signal.h

glibc 2.24
Post by jacobnavia
So, if you see a type called "u_int8_t" you should know is NOT an
integer with 8 bits but with 32!!!!!
What could be possibly the objective of that definition?
Mislead people into impossible to spot gotchas?
Gcc never ends to surprise me.
Do other linux distros have this definitions?
Ralf Damaschke
2017-07-29 14:39:39 UTC
Permalink
Raw Message
Post by jacobnavia
Definitely, signal.h is a strange file.
/usr/include/signal.h
224 typedef uint32_t u_int8_t ;
225 typedef uint32_t u_int16_t ;
226 typedef uint32_t u_int32_t ;
227 typedef uint32_t u_int64_t ;
???
!
Post by jacobnavia
So, if you see a type called "u_int8_t" you should know is NOT an
integer with 8 bits but with 32!!!!!
What could be possibly the objective of that definition?
May be these types are chosen internally for fastest access,
though nowadays "uint_fast8_t" etc. might be preferred.

Note that the names do not clash with the "stdint.h" names
and in POSIX type names ending with "_t" are reserved.
Post by jacobnavia
Do other linux distros have this definitions?
Mine, Ubuntu 14.04/gcc 4.8.4 does not (at least not there).
Joe Pfeiffer
2017-07-29 15:25:12 UTC
Permalink
Raw Message
Post by jacobnavia
Definitely, signal.h is a strange file.
/usr/include/signal.h
224 typedef uint32_t u_int8_t ;
225 typedef uint32_t u_int16_t ;
226 typedef uint32_t u_int32_t ;
227 typedef uint32_t u_int64_t ;
???
So, if you see a type called "u_int8_t" you should know is NOT an
integer with 8 bits but with 32!!!!!
What could be possibly the objective of that definition?
Mislead people into impossible to spot gotchas?
Gcc never ends to surprise me.
Do other linux distros have this definitions?
My /usr/include/signal.h has no such typedefs... I don't know if you
said already, but which distribution and what version of libc6-dev do
you have? (I ask about libc6-dev and not gcc because that's which
package provides my /usr/include/signal.h)

I'm running Debian, amd64, libc6-dev 2.24-12
jacobnavia
2017-07-29 15:41:46 UTC
Permalink
Raw Message
Post by jacobnavia
Do other linux distros have this definitions?
I searched in my other linux distros, and I do not find anything like
this, and all people here say they do NOT have anything like this.

I think this must be then either an error in the distro I am running on,
or even worst, a wrong manipulation by me where I screwed this file when
building my signal.h. I am running an arm64 distro.

Apologies to gcc and to the gcc team.
Keith Thompson
2017-07-29 22:30:07 UTC
Permalink
Raw Message
Post by jacobnavia
Post by jacobnavia
Do other linux distros have this definitions?
I searched in my other linux distros, and I do not find anything like
this, and all people here say they do NOT have anything like this.
I think this must be then either an error in the distro I am running on,
or even worst, a wrong manipulation by me where I screwed this file when
building my signal.h. I am running an arm64 distro.
Apologies to gcc and to the gcc team.
It would be helpful to know what distribution you're using, and what
version of glibc. (Remember, that file is provided by glibc, *not* by
gcc. You might as well blame tcc or clang, which use but do not provide
the same headers that gcc uses.)

Context from the parent article:

/usr/include/signal.h

contains this definitions:

224 typedef uint32_t u_int8_t ;
225 typedef uint32_t u_int16_t ;
226 typedef uint32_t u_int32_t ;
227 typedef uint32_t u_int64_t ;

glibc sources are maintained in a git repo. It currently contains 5
files named "signal.h". None of them contain those declarations in any
current or past revision.

The first few lines of your /usr/include/signal.h should indicate where
it came from.
--
Keith Thompson (The_Other_Keith) kst-***@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
David Brown
2017-07-29 23:32:44 UTC
Permalink
Raw Message
Post by Keith Thompson
Post by jacobnavia
Post by jacobnavia
Do other linux distros have this definitions?
I searched in my other linux distros, and I do not find anything like
this, and all people here say they do NOT have anything like this.
I think this must be then either an error in the distro I am running on,
or even worst, a wrong manipulation by me where I screwed this file when
building my signal.h. I am running an arm64 distro.
Apologies to gcc and to the gcc team.
It would be helpful to know what distribution you're using, and what
version of glibc. (Remember, that file is provided by glibc, *not* by
gcc. You might as well blame tcc or clang, which use but do not provide
the same headers that gcc uses.)
It is not clear that it is glibc at all. After all, this is an ARM
distribution for a fairly small device - it may be using an alternative
C standard library rather than glibc, such as "musl libc". Your other
points are equally valid in that case, but Jacob should confirm that it
is actually glibc in the first place.
Post by Keith Thompson
/usr/include/signal.h
224 typedef uint32_t u_int8_t ;
225 typedef uint32_t u_int16_t ;
226 typedef uint32_t u_int32_t ;
227 typedef uint32_t u_int64_t ;
glibc sources are maintained in a git repo. It currently contains 5
files named "signal.h". None of them contain those declarations in any
current or past revision.
The first few lines of your /usr/include/signal.h should indicate where
it came from.
jacobnavia
2017-07-30 10:58:27 UTC
Permalink
Raw Message
Post by David Brown
It is not clear that it is glibc at all. After all, this is an ARM
distribution for a fairly small device - it may be using an alternative
C standard library rather than glibc, such as "musl libc". Your other
points are equally valid in that case, but Jacob should confirm that it
is actually glibc in the first place.
This is a normal gcc installation, so I suppose glibc is used.
David Brown
2017-07-30 13:44:00 UTC
Permalink
Raw Message
Post by jacobnavia
Post by David Brown
It is not clear that it is glibc at all. After all, this is an ARM
distribution for a fairly small device - it may be using an
alternative C standard library rather than glibc, such as "musl
libc". Your other points are equally valid in that case, but Jacob
should confirm that it is actually glibc in the first place.
This is a normal gcc installation, so I suppose glibc is used.
"Normal" gcc installations, even native ones, can use different
libraries. Though glibc is the most common choice on Linux
distributions, small distributions often have different libraries.
That's why it is worth checking.
Keith Thompson
2017-07-30 21:04:04 UTC
Permalink
Raw Message
Post by jacobnavia
Post by David Brown
It is not clear that it is glibc at all. After all, this is an ARM
distribution for a fairly small device - it may be using an alternative
C standard library rather than glibc, such as "musl libc". Your other
points are equally valid in that case, but Jacob should confirm that it
is actually glibc in the first place.
This is a normal gcc installation, so I suppose glibc is used.
A "normal gcc installation"? I'm not at all sure what that means.

If you want help with this, you'll need to provide more information.
A comment block at the top of your signal.h file (the non-trivial
one, not the one-liner you're having problems with) should tell
you where it came from.

As I recall, the problem you're having is that *your* compiler
(lcc-something, I suppose) chokes on the .../sys/signal.h header;
gcc has no problem with it. That implies that gcc itself has
nothing directly to do with the problem you're having. It's about
the interaction between your compiler and the runtime library
implementation.

I've spent a fair amount of time trying to help you with this.
Please don't make me regret that.
--
Keith Thompson (The_Other_Keith) kst-***@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
jacobnavia
2017-07-30 21:15:33 UTC
Permalink
Raw Message
Post by Keith Thompson
If you want help with this, you'll need to provide more information.
A comment block at the top of your signal.h file (the non-trivial
one, not the one-liner you're having problems with) should tell
you where it came from.
1 /* Copyright (C) 1991-2014 Free Software Foundation, Inc.
2 This file is part of the GNU C Library.
3
4 The GNU C Library is free software; you can redistribute it and/or
5 modify it under the terms of the GNU Lesser General Public
6 License as published by the Free Software Foundation; either
7 version 2.1 of the License, or (at your option) any later version.
8
9 The GNU C Library is distributed in the hope that it will be useful,
10 but WITHOUT ANY WARRANTY; without even the implied warranty of
11 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
12 Lesser General Public License for more details.
13
14 You should have received a copy of the GNU Lesser General Public
15 License along with the GNU C Library; if not, see
16 <http://www.gnu.org/licenses/>. */
17
18 /*
19 * ISO C99 Standard: 7.14 Signal handling <signal.h>
20 */

This file is part of the Gnu C library it says, so it is a normal gcc
installation.

Look, I am developing mostly alone, so I need sometimes to know if a
problem is due to a gcc feature or just a wrong file or whatever.

That is why I asked that question, prematurely, as it seems. Here nobody
has the lines I found, so it must be some error or mistyping of my part,
not of the gcc installation precisely.

I acknowlezdged that fact, and went on working, after apologizing to the
gcc team that I implicitely blamed for that lines that very likely are a
mistake by me and not by them.

I do not care about gcc compatibility to the bone, as I did not care
with MSVC compatibility to the bone under windows. I just solved the
problem with supplying a modified signal.h and I will provide modified
headers for all standard headers when this port is more advanced.

And no, I do not think that lcc will compile the linux kernel.

So, gcc compatibility will be very limited.

If you want gcc, just use gcc!

jacob
Keith Thompson
2017-07-30 21:43:12 UTC
Permalink
Raw Message
Post by jacobnavia
Post by Keith Thompson
If you want help with this, you'll need to provide more information.
A comment block at the top of your signal.h file (the non-trivial
one, not the one-liner you're having problems with) should tell
you where it came from.
1 /* Copyright (C) 1991-2014 Free Software Foundation, Inc.
2 This file is part of the GNU C Library.
[snip]
Post by jacobnavia
This file is part of the Gnu C library it says, so it is a normal gcc
installation.
Why is it so hard for you to understand that the GNU C library
and gcc are two different things? They're certainly designed to
work together, but gcc is also designed to work with other library
implementations, and glibc (the GNU C Library) is designed to work,
with other compilers.

[...]
Post by jacobnavia
I do not care about gcc compatibility to the bone, as I did not care
with MSVC compatibility to the bone under windows. I just solved the
problem with supplying a modified signal.h and I will provide modified
headers for all standard headers when this port is more advanced.
No, you worked around the problem.

I'm still curious about the behavior of your compiler, particularly how
it searches for headers. If your compiler's behavior is within the
requirements of the standard, but violates some assumptions made by a
very widely used library implementation, that would be somewhat
interesting.

You're using a library implementation that has a ".../sys/signal.h" file
consisting of a single line:
#include <signal.h>
That seems perfectly sensible to me. Your compiler is having a problem
with it. Every compiler I've seen would handle it with no problem.

You ask for help, but you refuse to answer questions.
Post by jacobnavia
And no, I do not think that lcc will compile the linux kernel.
Um, I don't recall anyone suggesting that it should.
Post by jacobnavia
So, gcc compatibility will be very limited.
If you want gcc, just use gcc!
Which I do -- but your question has very little to do with gcc, so I'm
not sure why you bring it up.
--
Keith Thompson (The_Other_Keith) kst-***@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Loading...