Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #382356

Re: Effect of CPP tags

Show all headers | View raw

Kaz Kylheku <433-929-6894@kylheku.com> writes:

> On 2024-01-20, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>
>>> [...]  Just including <unistd.h> has undefined behavior as far as
>>> ISO C is concerned, [...]
>>
>> Not true.  The behavior of #include <unistd.h> is defined in
>> section 6.10.2 p2.  One of two things is true:  either the header
>> named is part of the implementation, or it isn't.  If the named
>> header is part of the implementation, then it constitutes a
>> language extension, and so it must be documented (and defined).
>
> The problem with this reasoning is
>
> 1. Implementations in fact have internal headers that are not
> documented, and which are not supposed to be included directly.
> You will not get documentation for every single header that
> is accessible via #include, and it is not reasonable for ISO C to
> require it.  I don't see where it does.

First, James Kuyper already identified section 4 paragraph 9.

Second, implementations do have lots of internal headers that are
not meant to be included directly, but just because such headers
exist doesn't mean they can be #include'd.  Consider these lines
at the start of <bits/byteswap.h>

 #if !defined _BYTESWAP_H && !defined _NETINET_IN_H && !defined _ENDIAN_H
 # error "Never use <bits/byteswap.h> directly; include <byteswap.h> instead."
 #endif

Clearly implementations can and do distinguish between headers
that are meant to be user #include-able and those that are not,
and take steps to protect the hidden ones.  It seems obvious
that implementations consider it reasonable to document headers
that are meant to be user #include-able, and to protect the
hidden headers so they can't be #included directly, because
that is what existing implementations do.

> 2. A documented extension continues to be undefined behavior.
> The behavior is "defined", but not "ISO C defined".  So even
> if all the implementation's internal headers were documented
> as extensions, their use would still be UB.
>
> Undefined behavior is for which "this document imposes not
> requirements", right?
>
> It is not behavior for which "this document, together with the
> ocumentation accompanying a given implementation, imposes
> no requirements".  Just "this document" (and no other).
>
> If "this document" imposes no requirements, it's "undefined
> behavior", no matter who or what imposes additional requirements!

Your logic here is all messed up.  The very first sentence uses
circular reasoning.  Next you ignore the point that the "define" in
section 4 paragraph 9 is a Standard-imposed requirement, and surely
the Standard means to require that implementations obey their own
definitions, because that's what "define" means.  The idea that
having to document extensions doesn't imply an ISO C requirement is
just being obtuse.

Perhaps a more fundamental flaw is you have the key implication
backwards.  IF using a particular program construct or data value
has been identified as undefined behavior, THEN the C standard
imposes no requirements on those uses.  The implication doesn't go
the other way.  For example, the C standard imposes no requirements
for what happens on Tuesdays.  That does not mean that compiling a
program on a Tuesday is undefined behavior.  The universe of
discourse is program constructs and data values ("values" here also
includes things such as trap representations).  Saying "an unknown
header is undefined behavior" is meaningless, because it's outside
the universe of discourse, just like Tuesdays are.  The C construct
in question is "#include <unistd.h>", and the C standard defines
behavior for that construct.

> Intuitively, a header which is part of an implementation can do
> anything.  For instance #include <pascal.h> can cause the rest of
> the translation unit to be analyzed as Pascal syntax, and not C.
>
> An implementation can provide a header <reboot.h>, including
> which causes a reboot at compile time, link time, or
> execution time.
>
> If such headers happen to exist, what in the standard is violated?

More bad logic.  Of course the contents of a header or #include'd
file can have, for example, syntax errors, that result in crossing
the line into undefined behavior.  The question is not whether an
unknown header /can/ cross the line into undefined behavior but
whether it /must/ cross that line.  Whether a #include of an unknown
header encounters undefined behavior depends on the contents of the
header, and nothing else.  A #include <unistd.h> MIGHT cross the
line into UB land, but there is nothing that says it MUST cross that
line.

Note by the way that exactly the same reasoning applies to an
unknown source file, such as #include "foo.h".  If we don't know
what's in foo.h (maybe it was left by a hacker in a little-used
byway of where the implementation looks for #include'd source
files), then undefined behavior is possible, but whether UB
actually happens depends only on the contents of the file, not on
whether we know what's in it.

> I used to experience a lot of push-back against the above views,
> but I'm seeing that people are coming around.

I expect that is simply a consequence of your dogged persistence
and the brighter people dropping out of the conversations.  It's
not whether some people start to be convinced, but rather which
people are convinced, and how firmly convinced, and why.

Back to comp.lang.c | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-12-28 15:12 -0800
  Re: Effect of CPP tags Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-20 14:29 -0800
    Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-21 04:46 +0000
      Re: Effect of CPP tags James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-21 10:56 -0500
      Re: Effect of CPP tags James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-21 12:11 -0500
        Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-21 17:55 +0000
          Re: Effect of CPP tags James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-21 21:57 -0500
            Re: Effect of CPP tags Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-24 07:42 -0800
          Re: Effect of CPP tags Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-31 12:43 -0800
            Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-31 13:41 -0800
              Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-02-01 09:19 +0100
              Re: Effect of CPP tags Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-03-14 23:11 -0700
                Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-14 23:56 -0700
              Re: Effect of CPP tags Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-03-14 23:12 -0700
      Re: Effect of CPP tags Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-11 17:38 -0800

csiph-web