Why doesn't cc -ansi disable conflicting type for getline from stdio.h?

[Edward Sanford Sutton, III]

Trying to work on properly learning C so following K&R second edition
of C Programming Language. Found in manpage that -std=c89 or -ansi can
be passed to setup a more compatible set of build rules which hid
warnings about how main is defined.
My understanding is that this should also cause getline to not be
defined in /usr/include/stdio.h. Is there a reason that "#if
__POSIX_VISIBLE >= 200809" should trigger as true in there with
-std=c89? Section 1.9 page 29 uses that function name in its own sample
code. I know I could rename it, but is there a way to disable this book
to modern compiler incompatibility from command line as I was
attempting? I've tried to call the compiler executable directly and also
attempted with /usr/local/bin/clang10 without different results. I tried
to disable ccache from environment variable setting but don't know how
to tell if that took effect properly nor would I expect it should be
relevant.
If you have a different starting suggestion for learning C then I'd be
interested but it seemed to be the guidance I found with internet
searching and other starter books I own usually mix c and c++ with more
of a c++ and nonunix focus. Also trying to work on learning vi while
doing this; hard to wrap my brain around insert (sometimes?) backing me
up 1 character when exiting the mode.
If helpful I can include the code I typed form the page of text, or a
smaller example showing the problem. Below is compiler command with
output and /usr/lib/clang/11.0.1/include does not have a copy of stdio.h
that I see.

/usr/bin/clang -ansi -v characterarrays.c
FreeBSD clang version 11.0.1 (g...@github.com:llvm/llvm-project.git
llvmorg-11.0.1-0-g43ff75f2c3fe)
Target: x86_64-unknown-freebsd13.0
Thread model: posix
InstalledDir: /usr/bin
"/usr/bin/clang" -cc1 -triple x86_64-unknown-freebsd13.0 -emit-obj
-mrelax-all -disable-free -disable-llvm-verifier -discard-value-names
-main-file-name characterarrays.c -mrelocation-model static
-mframe-pointer=all -fno-rounding-math -mconstructor-aliases
-munwind-tables -target-cpu x86-64 -fno-split-dwarf-inlining
-debugger-tuning=gdb -v -resource-dir /usr/lib/clang/11.0.1 -std=c89
-fdebug-compilation-dir /home/mirror176/programming/k&r -ferror-limit 19
-fgnuc-version=4.2.1 -fcolor-diagnostics -faddrsig -o
/tmp/characterarrays-a7e144.o -x c characterarrays.c
clang -cc1 version 11.0.1 based upon LLVM 11.0.1 default target
x86_64-unknown-freebsd13.0
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/clang/11.0.1/include
/usr/include
End of search list.
characterarrays.c:4:5: error: conflicting types for 'getline'
int getline(char line[], int maxline);
^
/usr/include/stdio.h:380:10: note: previous declaration is here
ssize_t getline(char ** __restrict, size_t * __restrict, FILE *
__restrict);
^
characterarrays.c:16:37: error: too few arguments to function call,
expected 3, have 2
while ((len = getline(line, MAXLINE)) > 0)
~~~~~~~ ^
/usr/include/stdio.h:380:10: note: 'getline' declared here
ssize_t getline(char ** __restrict, size_t * __restrict, FILE *
__restrict);
^
characterarrays.c:27:5: error: conflicting types for 'getline'
int getline(char a[], int lim)
^
/usr/include/stdio.h:380:10: note: previous declaration is here
ssize_t getline(char ** __restrict, size_t * __restrict, FILE *
__restrict);
^
characterarrays.c:31:45: error: use of undeclared identifier 'c1'
for (i=0; i<lim-1 && (c=getchar())!=EOF && c1='\n'; ++i)
^
characterarrays.c:32:3: error: use of undeclared identifier 's'
s[i]=c;
^
characterarrays.c:33:11: warning: multi-character character constant
[-Wmultichar]
if (c == '/n') {
^
characterarrays.c:34:3: error: use of undeclared identifier 's'
s[i] = c;
^
characterarrays.c:37:2: error: use of undeclared identifier 's'
s[i] = '\0';
^
1 warning and 7 errors generated.

Thanks,
Edward Sutton, III

[Kurt Hackenberg]

On 2021/06/14 17:10, Edward Sanford Sutton, III wrote:

> Trying to work on properly learning C so following K&R second edition
> of C Programming Language. Found in manpage that -std=c89 or -ansi can
> be passed to setup a more compatible set of build rules which hid
> warnings about how main is defined.
> My understanding is that this should also cause getline to not be
> defined in /usr/include/stdio.h. Is there a reason that "#if
> __POSIX_VISIBLE >= 200809" should trigger as true in there with
> -std=c89?

Huh. I didn't know about that function getline() as part of the C
library. The latest C reference I have is for C99, 1999; it doesn't
include getline().

You may have run across dueling standards or something. Posix defines a
standard Unix, and apparently also defines a C standard library that's a
little larger than the C standard library defined by the C standard,
even though Posix doesn't define C. (Yes, that's a little weird.)

<https://en.wikipedia.org/wiki/POSIX>
<https://en.wikipedia.org/wiki/C_POSIX_library>

The boundary between C and Unix has always been blurred a little in
practice. It's good to keep the boundary clear in your mind, but you
might have to accept some imperfection in software.

I suggest you take that getline() thing as a glitch, the kind of thing
that shows up in old software[1], and work around it without worrying
about it too much. Definitely rename the function in the sample program.

As for learning C, K & R is the classic for that, but it's 30 years old.
I suggest that you go through that, and when you more or less have a
handle on the language, also look at more modern versions of C. There
were significant changes in 1999 and 2011 -- not fundamental changes,
but some useful additions.


[1] C and Unix are 50 years old! That's pretty damn old for software.
_______________________________________________
freebsd-...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questi...@freebsd.org"

[Ronald F. Guilmette]

In message <4018acc9-2607-67ed...@panix.com>,

Kurt Hackenberg <k...@panix.com> wrote:

>The boundary between C and Unix has always been blurred a little in

>practice. It's good to keep the boundary clear in your mind...

But but but...that's no longer necessary now that EVERYTHING is UNIX,
right? So if you have a C compiler, and it isn't cross targeting for
some embedded sysetem, then you likely have all of the UNIX primitives
and all of the standard UNIX anmd POSIX C libraries at your disposal.

Didn't a read a few years ago that Windoze had basically absorbed all of
UNIX and that it now provides al of the same stuff, via libraries?

Or maybe I misunderstood.

It certainly seemed consistant with Microsoft's well publicised "embrace,
extend, and destroy" philosophy at the time I read that.


Regards,
rfg

[Arthur Chance]

On 16/06/2021 07:18, Ronald F. Guilmette wrote:
> In message <4018acc9-2607-67ed...@panix.com>,
> Kurt Hackenberg <k...@panix.com> wrote:
>
>> The boundary between C and Unix has always been blurred a little in
>> practice. It's good to keep the boundary clear in your mind...
>
> But but but...that's no longer necessary now that EVERYTHING is UNIX,
> right? So if you have a C compiler, and it isn't cross targeting for
> some embedded sysetem, then you likely have all of the UNIX primitives
> and all of the standard UNIX anmd POSIX C libraries at your disposal.

Technically the C standard allows for hosted C environments on any
operating system, so there may be a C17 implementation running on an
emulation of Multics somewhere.

> Didn't a read a few years ago that Windoze had basically absorbed all of
> UNIX and that it now provides al of the same stuff, via libraries?
>
> Or maybe I misunderstood.
>
> It certainly seemed consistant with Microsoft's well publicised "embrace,
> extend, and destroy" philosophy at the time I read that.

You're thinking of WSL (Windows System for Linux). With the release of
WSL 2 you've got Linux compatibiity (and it's sometimes faster than
native Windows code).

--
Lebowskisort, aka dudesort, an O(1) sorting algorithm:

"Man, the array is cool as it is. Let's go bowling."

[Ronald F. Guilmette]

In message <8033286d-cfb8-59a3...@qeng-ho.org>,

Arthur Chance <fre...@qeng-ho.org> wrote:

>> Didn't a read a few years ago that Windoze had basically absorbed all of
>> UNIX and that it now provides al of the same stuff, via libraries?
>>
>> Or maybe I misunderstood.
>>
>> It certainly seemed consistant with Microsoft's well publicised "embrace,
>> extend, and destroy" philosophy at the time I read that.
>
>You're thinking of WSL (Windows System for Linux).

Yes, apparently. (I'm reading the Wikipedia page on that now. Thanks
for giving me the name of the thing, so that I could google it.)

I'm sure that this "WSL 2" thing is swell for some projects, but
for me personally it just looks like more lipstick on the pig.


Regards,
rfg

[Norman Gray]

Greetings.

On 16 Jun 2021, at 23:06, Ronald F. Guilmette wrote:

>> You're thinking of WSL (Windows System for Linux).
>
> Yes, apparently. (I'm reading the Wikipedia page on that now. Thanks
> for giving me the name of the thing, so that I could google it.)
>
> I'm sure that this "WSL 2" thing is swell for some projects, but
> for me personally it just looks like more lipstick on the pig.

Apropos of not very much, I'll chip in at this point to say that WSL2 is
interestingly and unexpectedly good, in an 'it just works' sense.

Example 1: I recently taught an 'Introduction to unix tools' course,
with a mixed-OS class. Unlike WSL1 or (OMG) cygnus in previous years,
once the WSL2 students had been shown how to enable WSL2 on their
Windows machines (admittedly not trivial in every case), they were
officially No Problem, being less of a drain on lab demonstrator time
than the students with random Linux distributions.

Example 2: In a recent project, I was collaborating with a firmly
Windows-based colleague on an Arduino project, where the build toolchain
used slightly fragile Makefiles invoking (on their machine, via WSL2)
the Windows install of the Arduino cross-compilers. This turned out to
be massively less of a problem than I expected it to be. It's not
bulletproof, and there's non-zero scope for filesystem-confusion -- at
one point, if I recall correctly, the Makefile and the compiler turned
out to have different ideas about what 'the home directory' was, and
where ../ went from there (oooh, the hilarity) -- but these were at the
level of unix-to-unix porting problems, rather than anything more
hair-pullingly entertaining.

I think it's possible to get X running on WSL2, but that's only for
masochists. MS are not going to help you with that at all. It all ends
up feeling agreeably old-skool.

Best wishes,

Norman


--
Norman Gray : http://www.astro.gla.ac.uk/users/norman/it/
Research IT Coordinator
SUPA School of Physics and Astronomy, University of Glasgow, UK
Charity number SC004401