char get_char(const char *format, ...) __attribute__((format(printf, 1,
2)));

I downloaded a free library file from this link:
<https://github.com/cs50/libcs50/releases>

But when I try to compile it, it faults at line 58 and other lines
containing attribute world. So what exactly is likely to be wrong with it.?
The library was created by Harvard uni for students to learn C
programming so it must work on a Windows system using visual Studio, but
it doesn't. What changes should I make to make it work?

Jack Lemmon <invalid@invalid.net> writes:
>
>char get_char(const char *format, ...) __attribute__((format(printf, 1,
>2)));
>
>I downloaded a free library file from this link:
><https://github.com/cs50/libcs50/releases>
>
>But when I try to compile it, it faults at line 58 and other lines
>containing attribute world. So what exactly is likely to be wrong with it.?
>The library was created by Harvard uni for students to learn C
>programming so it must work on a Windows system using visual Studio, but

Evidence doesn't support the conclusion.

>it doesn't. What changes should I make to make it work?

Don't use Microsoft compilers.

__attribute__ is a GCC extension.

On Mon, 18 Apr 2022 17:44:25 +0100, Jack Lemmon wrote:

> char get_char(const char *format, ...) __attribute__((format(printf, 1,
> 2)));

__attribute__ isn't a standard C keyword (or even a standard C anything).
It is, however, an extension to the C language implemented in the GNU C
compiler.

> I downloaded a free library file from this link:
> <https://github.com/cs50/libcs50/releases>
>
> But when I try to compile it, it faults at line 58 and other lines
> containing attribute world. So what exactly is likely to be wrong with it.?
> The library was created by Harvard uni for students to learn C
> programming so it must work

Yah, faulty assumption there...

> on a Windows system using visual Studio, but

The Microsoft Visual Studio does not support the GCC __attribute__ extension
to the C language. To properly compile libcs50, you will need a GNU C compiler.

> it doesn't. What changes should I make to make it work?

HTH
--
Lew Pitcher
"In Skills, We Trust"

On 18/04/2022 18:44, Jack Lemmon wrote:
>
> char get_char(const char *format, ...) __attribute__((format(printf, 1,
> 2)));
>
> I downloaded a free library file from this link:
> <https://github.com/cs50/libcs50/releases>
>
> But when I try to compile it, it faults at line 58 and other lines
> containing attribute world. So what exactly is likely to be wrong with it.?
> The library was created by Harvard uni for students to learn C
> programming so it must work on a Windows system using visual Studio, but
> it doesn't. What changes should I make to make it work?
>

Windows and Visual Studio are very questionable choices for learning C -
MSVC has a good reputation for C++ AFAIK, but much poorer for C as it is
simply not a commonly used language for Windows programming.

The __attribute__ syntax is a gcc extension, not standard C. It is
supported by a number of other C compilers, including clang and icc, but
not by Microsoft's tools. (Some of there tools are designed to work
with third-party compilers such as clang and gcc, but I have no
experience with them - maybe their IDE will still complain about such
extensions.)

In article <t3k4n3$1ba2l$1@paganini.bofh.team>,
Jack Lemmon <invalid@invalid.net> wrote:
>
>char get_char(const char *format, ...) __attribute__((format(printf, 1,
>2)));
>
>I downloaded a free library file from this link:
><https://github.com/cs50/libcs50/releases>
>
>But when I try to compile it, it faults at line 58 and other lines
>containing attribute world. So what exactly is likely to be wrong with it.?
>The library was created by Harvard uni for students to learn C
>programming so it must work on a Windows system using visual Studio, but
>it doesn't. What changes should I make to make it work?

The real answer to your query is: Ask your instructor which compiler you are
supposed to be using (for whatever platform you are supposed to be using).

--
A Catholic woman tells her husband to buy Viagra.

A Jewish woman tells her husband to buy Pfizer.

On 4/18/2022 9:44 AM, Jack Lemmon wrote:
>
> char get_char(const char *format, ...) __attribute__((format(printf, 1,
> 2)));
>
> I downloaded a free library file from this link:
> <https://github.com/cs50/libcs50/releases>
>
> But when I try to compile it, it faults at line 58 and other lines
> containing attribute world. So what exactly is likely to be wrong with it.?
> The library was created by Harvard uni for students to learn C
> programming so it must work on a Windows system using visual Studio, but
> it doesn't. What changes should I make to make it work?

It is low quality code apparently originating from some educational
institution in USA. Harvard, you said? Avoid code with such questionable
origins - it is usually garbage. The code you quoted is written
exclusively for GCC and apparently exclusively for the internal
educational purposes. It uses some motley non-standard GCC extensions.
And no effort was made to make it transparently portable to other
compilers, including especially Visual Studio.

When code does not compile in Visual Studio it is effectively useless.
Compatibility with Visual Studio is a hard requirement for all C and C++
code in professional world.

--
Best regards,
Andrey Tarasevich

On 19/04/2022 02:32, Andrey Tarasevich wrote:
> On 4/18/2022 9:44 AM, Jack Lemmon wrote:
>>
>> char get_char(const char *format, ...) __attribute__((format(printf, 1,
>> 2)));
>>
>> I downloaded a free library file from this link:
>> <https://github.com/cs50/libcs50/releases>
>>
>> But when I try to compile it, it faults at line 58 and other lines
>> containing attribute world. So what exactly is likely to be wrong with
>> it.?
>> The library was created by Harvard uni for students to learn C
>> programming so it must work on a Windows system using visual Studio, but
>> it doesn't. What changes should I make to make it work?
>
> It is low quality code apparently originating from some educational
> institution in USA. Harvard, you said? Avoid code with such questionable
> origins - it is usually garbage. The code you quoted is written
> exclusively for GCC and apparently exclusively for the internal
> educational purposes. It uses some motley non-standard GCC extensions.
> And no effort was made to make it transparently portable to other
> compilers, including especially Visual Studio.
>
> When code does not compile in Visual Studio it is effectively useless.
> Compatibility with Visual Studio is a hard requirement for all C and C++
> code in professional world.
>

I assume that last paragraph is sarcasm. But given the original
question, the OP might not understand that.

Some code is written to be widely portable. Other code is not. That is
fine, and entirely appropriate use of the languages and tools.
Pointlessly non-portable code is a bad habit - but so is pointlessly
portable code.

C is rarely used for Windows programming, and MSVC is rarely used for C
on Windows. Therefore it usually makes little sense to go out of your
way to worry about making your C code compatible with MS tools.

(I haven't bothered to look at the code in question, and can't comment
on its purpose or quality.)

On Tuesday, 19 April 2022 at 08:55:50 UTC+1, David Brown wrote:
> On 19/04/2022 02:32, Andrey Tarasevich wrote:
> > On 4/18/2022 9:44 AM, Jack Lemmon wrote:
> >>
> >> char get_char(const char *format, ...) __attribute__((format(printf, 1,
> >> 2)));
> >>
> >> I downloaded a free library file from this link:
> >> <https://github.com/cs50/libcs50/releases>
> >>
> >> But when I try to compile it, it faults at line 58 and other lines
> >> containing attribute world. So what exactly is likely to be wrong with
> >> it.?
> >> The library was created by Harvard uni for students to learn C
> >> programming so it must work on a Windows system using visual Studio, but
> >> it doesn't. What changes should I make to make it work?
> >
> > It is low quality code apparently originating from some educational
> > institution in USA. Harvard, you said? Avoid code with such questionable
> > origins - it is usually garbage. The code you quoted is written
> > exclusively for GCC and apparently exclusively for the internal
> > educational purposes. It uses some motley non-standard GCC extensions.
> > And no effort was made to make it transparently portable to other
> > compilers, including especially Visual Studio.
> >
> > When code does not compile in Visual Studio it is effectively useless.
> > Compatibility with Visual Studio is a hard requirement for all C and C++
> > code in professional world.
> >
> I assume that last paragraph is sarcasm. But given the original
> question, the OP might not understand that.
>
> Some code is written to be widely portable. Other code is not. That is
> fine, and entirely appropriate use of the languages and tools.
> Pointlessly non-portable code is a bad habit - but so is pointlessly
> portable code.
>
You make it sound as if it's a mirror image.

You can make code too portable, for instance by passing in function pointers
to break the dependency on IO, when in fact there is a soft dependency there
anyway because the the function makes certain assumptions about the
operations available via the IO, and when it would be far clearer to simply
call IO directly. But I've rarely seen this.

Code that should be portable but has some dependency somewhere which
could have been easily refactored out, you see all of the time.

On 19/04/2022 11:32, Malcolm McLean wrote:
> On Tuesday, 19 April 2022 at 08:55:50 UTC+1, David Brown wrote:
>> On 19/04/2022 02:32, Andrey Tarasevich wrote:
>>> On 4/18/2022 9:44 AM, Jack Lemmon wrote:
>>>>
>>>> char get_char(const char *format, ...) __attribute__((format(printf, 1,
>>>> 2)));
>>>>
>>>> I downloaded a free library file from this link:
>>>> <https://github.com/cs50/libcs50/releases>
>>>>
>>>> But when I try to compile it, it faults at line 58 and other lines
>>>> containing attribute world. So what exactly is likely to be wrong with
>>>> it.?
>>>> The library was created by Harvard uni for students to learn C
>>>> programming so it must work on a Windows system using visual Studio, but
>>>> it doesn't. What changes should I make to make it work?
>>>
>>> It is low quality code apparently originating from some educational
>>> institution in USA. Harvard, you said? Avoid code with such questionable
>>> origins - it is usually garbage. The code you quoted is written
>>> exclusively for GCC and apparently exclusively for the internal
>>> educational purposes. It uses some motley non-standard GCC extensions.
>>> And no effort was made to make it transparently portable to other
>>> compilers, including especially Visual Studio.
>>>
>>> When code does not compile in Visual Studio it is effectively useless.
>>> Compatibility with Visual Studio is a hard requirement for all C and C++
>>> code in professional world.
>>>
>> I assume that last paragraph is sarcasm. But given the original
>> question, the OP might not understand that.
>>
>> Some code is written to be widely portable. Other code is not. That is
>> fine, and entirely appropriate use of the languages and tools.
>> Pointlessly non-portable code is a bad habit - but so is pointlessly
>> portable code.
>>
> You make it sound as if it's a mirror image.
>
> You can make code too portable, for instance by passing in function pointers
> to break the dependency on IO, when in fact there is a soft dependency there
> anyway because the the function makes certain assumptions about the
> operations available via the IO, and when it would be far clearer to simply
> call IO directly. But I've rarely seen this.
>
> Code that should be portable but has some dependency somewhere which
> could have been easily refactored out, you see all of the time.

I'm sorry, I have /no/ idea why you are talking about function pointers
and "soft dependencies" (whatever that might mean).

A lot of code has parts that are easily portable to a fairly wide range
of targets (processor, compiler, OS) and also parts that are much more
dependent on aspects of the target. If you are writing a program that
is targeting Windows only, and aimed for MSVC, then it makes sense to
accept that non-portability if it lets you use extra non-portable
features that improve your code in some way. The same applies if you
are targeting gcc and POSIX, or an embedded system, or anything else.
Most real-world practical code does not need to be particularly portable.

It can often be practical to have a compatibility layer - a header that
has conditional compilation and defines macros or other features, so
that code can be compiled on different toolchains.

It is usually hard to predict where your code might end up in the
future, so reasonable portability is a good thing. But there is no
point in writing code in a way that is unrealistically portable.

On Tuesday, 19 April 2022 at 11:54:59 UTC+1, David Brown wrote:
> On 19/04/2022 11:32, Malcolm McLean wrote:
> > On Tuesday, 19 April 2022 at 08:55:50 UTC+1, David Brown wrote:
> >> On 19/04/2022 02:32, Andrey Tarasevich wrote:
> >>> On 4/18/2022 9:44 AM, Jack Lemmon wrote:
> >>>>
> >>>> char get_char(const char *format, ...) __attribute__((format(printf, 1,
> >>>> 2)));
> >>>>
> >>>> I downloaded a free library file from this link:
> >>>> <https://github.com/cs50/libcs50/releases>
> >>>>
> >>>> But when I try to compile it, it faults at line 58 and other lines
> >>>> containing attribute world. So what exactly is likely to be wrong with
> >>>> it.?
> >>>> The library was created by Harvard uni for students to learn C
> >>>> programming so it must work on a Windows system using visual Studio, but
> >>>> it doesn't. What changes should I make to make it work?
> >>>
> >>> It is low quality code apparently originating from some educational
> >>> institution in USA. Harvard, you said? Avoid code with such questionable
> >>> origins - it is usually garbage. The code you quoted is written
> >>> exclusively for GCC and apparently exclusively for the internal
> >>> educational purposes. It uses some motley non-standard GCC extensions.
> >>> And no effort was made to make it transparently portable to other
> >>> compilers, including especially Visual Studio.
> >>>
> >>> When code does not compile in Visual Studio it is effectively useless.
> >>> Compatibility with Visual Studio is a hard requirement for all C and C++
> >>> code in professional world.
> >>>
> >> I assume that last paragraph is sarcasm. But given the original
> >> question, the OP might not understand that.
> >>
> >> Some code is written to be widely portable. Other code is not. That is
> >> fine, and entirely appropriate use of the languages and tools.
> >> Pointlessly non-portable code is a bad habit - but so is pointlessly
> >> portable code.
> >>
> > You make it sound as if it's a mirror image.
> >
> > You can make code too portable, for instance by passing in function pointers
> > to break the dependency on IO, when in fact there is a soft dependency there
> > anyway because the the function makes certain assumptions about the
> > operations available via the IO, and when it would be far clearer to simply
> > call IO directly. But I've rarely seen this.
> >
> > Code that should be portable but has some dependency somewhere which
> > could have been easily refactored out, you see all of the time.
> I'm sorry, I have /no/ idea why you are talking about function pointers
> and "soft dependencies" (whatever that might mean).
>
Function pointers are an important tool for removing problem- or platform-
specific code from the main logical core of the application. A hard dependency
is when A makes a direct reference to B, in the simplest case, because A
calls B. We can remove the dependency by adding a layer of indirection, so we
can now replace B with C, D, E etc. However it's a "soft dependency" if it turns
out that the characteristics required of C, D, E etc are so narrow, that to all
intents and purposes, they are required to be B, and in reality the system will
need reengineering if B is not avaliable.

On 19/04/2022 13:31, Malcolm McLean wrote:
> On Tuesday, 19 April 2022 at 11:54:59 UTC+1, David Brown wrote:
>> On 19/04/2022 11:32, Malcolm McLean wrote:
>>> On Tuesday, 19 April 2022 at 08:55:50 UTC+1, David Brown wrote:
>>>> On 19/04/2022 02:32, Andrey Tarasevich wrote:
>>>>> On 4/18/2022 9:44 AM, Jack Lemmon wrote:
>>>>>>
>>>>>> char get_char(const char *format, ...) __attribute__((format(printf, 1,
>>>>>> 2)));
>>>>>>
>>>>>> I downloaded a free library file from this link:
>>>>>> <https://github.com/cs50/libcs50/releases>
>>>>>>
>>>>>> But when I try to compile it, it faults at line 58 and other lines
>>>>>> containing attribute world. So what exactly is likely to be wrong with
>>>>>> it.?
>>>>>> The library was created by Harvard uni for students to learn C
>>>>>> programming so it must work on a Windows system using visual Studio, but
>>>>>> it doesn't. What changes should I make to make it work?
>>>>>
>>>>> It is low quality code apparently originating from some educational
>>>>> institution in USA. Harvard, you said? Avoid code with such questionable
>>>>> origins - it is usually garbage. The code you quoted is written
>>>>> exclusively for GCC and apparently exclusively for the internal
>>>>> educational purposes. It uses some motley non-standard GCC extensions.
>>>>> And no effort was made to make it transparently portable to other
>>>>> compilers, including especially Visual Studio.
>>>>>
>>>>> When code does not compile in Visual Studio it is effectively useless.
>>>>> Compatibility with Visual Studio is a hard requirement for all C and C++
>>>>> code in professional world.
>>>>>
>>>> I assume that last paragraph is sarcasm. But given the original
>>>> question, the OP might not understand that.
>>>>
>>>> Some code is written to be widely portable. Other code is not. That is
>>>> fine, and entirely appropriate use of the languages and tools.
>>>> Pointlessly non-portable code is a bad habit - but so is pointlessly
>>>> portable code.
>>>>
>>> You make it sound as if it's a mirror image.
>>>
>>> You can make code too portable, for instance by passing in function pointers
>>> to break the dependency on IO, when in fact there is a soft dependency there
>>> anyway because the the function makes certain assumptions about the
>>> operations available via the IO, and when it would be far clearer to simply
>>> call IO directly. But I've rarely seen this.
>>>
>>> Code that should be portable but has some dependency somewhere which
>>> could have been easily refactored out, you see all of the time.
>> I'm sorry, I have /no/ idea why you are talking about function pointers
>> and "soft dependencies" (whatever that might mean).
>>
> Function pointers are an important tool for removing problem- or platform-
> specific code from the main logical core of the application. A hard dependency
> is when A makes a direct reference to B, in the simplest case, because A
> calls B. We can remove the dependency by adding a layer of indirection, so we
> can now replace B with C, D, E etc. However it's a "soft dependency" if it turns
> out that the characteristics required of C, D, E etc are so narrow, that to all
> intents and purposes, they are required to be B, and in reality the system will
> need reengineering if B is not avaliable.
>

Okay, so as I thought the term "soft dependency" is your own personal
and subjective term, and like function pointers it is not relevant to
the discussion or of any help to the OP. So let's leave it there.

On Tuesday, 19 April 2022 at 12:51:54 UTC+1, David Brown wrote:
> On 19/04/2022 13:31, Malcolm McLean wrote:
> > On Tuesday, 19 April 2022 at 11:54:59 UTC+1, David Brown wrote:
> >> On 19/04/2022 11:32, Malcolm McLean wrote:
> >>> On Tuesday, 19 April 2022 at 08:55:50 UTC+1, David Brown wrote:
> >>>> On 19/04/2022 02:32, Andrey Tarasevich wrote:
> >>>>> On 4/18/2022 9:44 AM, Jack Lemmon wrote:
> >>>>>>
> >>>>>> char get_char(const char *format, ...) __attribute__((format(printf, 1,
> >>>>>> 2)));
> >>>>>>
> >>>>>> I downloaded a free library file from this link:
> >>>>>> <https://github.com/cs50/libcs50/releases>
> >>>>>>
> >>>>>> But when I try to compile it, it faults at line 58 and other lines
> >>>>>> containing attribute world. So what exactly is likely to be wrong with
> >>>>>> it.?
> >>>>>> The library was created by Harvard uni for students to learn C
> >>>>>> programming so it must work on a Windows system using visual Studio, but
> >>>>>> it doesn't. What changes should I make to make it work?
> >>>>>
> >>>>> It is low quality code apparently originating from some educational
> >>>>> institution in USA. Harvard, you said? Avoid code with such questionable
> >>>>> origins - it is usually garbage. The code you quoted is written
> >>>>> exclusively for GCC and apparently exclusively for the internal
> >>>>> educational purposes. It uses some motley non-standard GCC extensions.
> >>>>> And no effort was made to make it transparently portable to other
> >>>>> compilers, including especially Visual Studio.
> >>>>>
> >>>>> When code does not compile in Visual Studio it is effectively useless.
> >>>>> Compatibility with Visual Studio is a hard requirement for all C and C++
> >>>>> code in professional world.
> >>>>>
> >>>> I assume that last paragraph is sarcasm. But given the original
> >>>> question, the OP might not understand that.
> >>>>
> >>>> Some code is written to be widely portable. Other code is not. That is
> >>>> fine, and entirely appropriate use of the languages and tools.
> >>>> Pointlessly non-portable code is a bad habit - but so is pointlessly
> >>>> portable code.
> >>>>
> >>> You make it sound as if it's a mirror image.
> >>>
> >>> You can make code too portable, for instance by passing in function pointers
> >>> to break the dependency on IO, when in fact there is a soft dependency there
> >>> anyway because the the function makes certain assumptions about the
> >>> operations available via the IO, and when it would be far clearer to simply
> >>> call IO directly. But I've rarely seen this.
> >>>
> >>> Code that should be portable but has some dependency somewhere which
> >>> could have been easily refactored out, you see all of the time.
> >> I'm sorry, I have /no/ idea why you are talking about function pointers
> >> and "soft dependencies" (whatever that might mean).
> >>
> > Function pointers are an important tool for removing problem- or platform-
> > specific code from the main logical core of the application. A hard dependency
> > is when A makes a direct reference to B, in the simplest case, because A
> > calls B. We can remove the dependency by adding a layer of indirection, so we
> > can now replace B with C, D, E etc. However it's a "soft dependency" if it turns
> > out that the characteristics required of C, D, E etc are so narrow, that to all
> > intents and purposes, they are required to be B, and in reality the system will
> > need reengineering if B is not avaliable.
> >
> Okay, so as I thought the term "soft dependency" is your own personal
> and subjective term, and like function pointers it is not relevant to
> the discussion or of any help to the OP. So let's leave it there.
>
As far as I'm aware I'm the first person to use the term "soft dependency",
though I doubt the issue has not been identified by many other people before.
The words "hard" and "soft" have fairly well accepted meanings, and I was
not using the term in a "subjective" way.

Andrey Tarasevich <andreytarasevich@hotmail.com> writes:
>On 4/18/2022 9:44 AM, Jack Lemmon wrote:

>When code does not compile in Visual Studio it is effectively useless.
>Compatibility with Visual Studio is a hard requirement for all C and C++
>code in professional world.

Now that's funny. I've been programming "in the professional world",
in C and C++ for forty years, and Visual Studio has _never_ been part
of that process. It's been considered a toy compiler by most.

On Tuesday, 19 April 2022 at 15:07:48 UTC+1, Scott Lurndal wrote:
> Andrey Tarasevich <andreyta...@hotmail.com> writes:
> >On 4/18/2022 9:44 AM, Jack Lemmon wrote:
>
> >When code does not compile in Visual Studio it is effectively useless.
> >Compatibility with Visual Studio is a hard requirement for all C and C++
> >code in professional world.
> Now that's funny. I've been programming "in the professional world",
> in C and C++ for forty years, and Visual Studio has _never_ been part
> of that process. It's been considered a toy compiler by most.
>
It's not a good C compiler. But it's the most realistic option for compiling
Windows programs, and there are often good reasons for writing programs
to run on Windows.
If you stick to a conservative subset of C89, you should be OK. So MSVC
is a reason for sticking to that conservative subset.

On 4/19/2022 4:43 PM, Malcolm McLean wrote:
> On Tuesday, 19 April 2022 at 15:07:48 UTC+1, Scott Lurndal wrote:
>> Andrey Tarasevich <andreyta...@hotmail.com> writes:
>>> On 4/18/2022 9:44 AM, Jack Lemmon wrote:
>>
>>> When code does not compile in Visual Studio it is effectively useless.
>>> Compatibility with Visual Studio is a hard requirement for all C and C++
>>> code in professional world.
>> Now that's funny. I've been programming "in the professional world",
>> in C and C++ for forty years, and Visual Studio has _never_ been part
>> of that process. It's been considered a toy compiler by most.
>>
> It's not a good C compiler. But it's the most realistic option for compiling
> Windows programs, and there are often good reasons for writing programs
> to run on Windows.
> If you stick to a conservative subset of C89, you should be OK. So MSVC
> is a reason for sticking to that conservative subset.

I'd even say that /if/ you need to target Windows, it's probably the
best compiler for the job, in the sense that the benefit of platform
compatibility wins over the cost of lower standard compliance.

However, the main fact is that MSVC is primarily designed as a C++
compiler, and even if, as you say, there are good reason to write
programs for Windows, most often these are C++ programs, rather than C.

On 4/18/22 20:32, Andrey Tarasevich wrote:
....
> When code does not compile in Visual Studio it is effectively useless.
> Compatibility with Visual Studio is a hard requirement for all C and
> C++ code in professional world.

I've spent a quarter century as a professional computer programmer
working on projects where compatibility with Visual Studios was not a
requirement, or even a priority. Our code was required to conform to the
C standard. We were allowed to assume POSIX conformance (though we made
little use of that fact other than the fact that our build scripts were
intended for POSIX sh, and our make files were intended for the POSIX
make utility). We were otherwise prohibited from writing
platform-specific code (not even if protected by #if* directives based
upon platform-specific macros) - that includes depending upon gcc
extensions.

On Tuesday, 19 April 2022 at 16:40:11 UTC+1, Manfred wrote:
> On 4/19/2022 4:43 PM, Malcolm McLean wrote:
> > On Tuesday, 19 April 2022 at 15:07:48 UTC+1, Scott Lurndal wrote:
> >> Andrey Tarasevich <andreyta...@hotmail.com> writes:
> >>> On 4/18/2022 9:44 AM, Jack Lemmon wrote:
> >>
> >>> When code does not compile in Visual Studio it is effectively useless.
> >>> Compatibility with Visual Studio is a hard requirement for all C and C++
> >>> code in professional world.
> >> Now that's funny. I've been programming "in the professional world",
> >> in C and C++ for forty years, and Visual Studio has _never_ been part
> >> of that process. It's been considered a toy compiler by most.
> >>
> > It's not a good C compiler. But it's the most realistic option for compiling
> > Windows programs, and there are often good reasons for writing programs
> > to run on Windows.
> > If you stick to a conservative subset of C89, you should be OK. So MSVC
> > is a reason for sticking to that conservative subset.
> I'd even say that /if/ you need to target Windows, it's probably the
> best compiler for the job, in the sense that the benefit of platform
> compatibility wins over the cost of lower standard compliance.
>
> However, the main fact is that MSVC is primarily designed as a C++
> compiler, and even if, as you say, there are good reason to write
> programs for Windows, most often these are C++ programs, rather than C.
>
If you know that the program will be targetted at Windows, and never
run on any other platform, then generally you should go for C++ or C sharp,
because of better compiler support.
But if you are writing a general purpose routine, it will be easier to integrate
with other code if it is in C. It can be given C++, C sharp, Objective C, or
Python bindings quite easily. But it does need to compile under Visual C.
So you should be quite conservative in your choice of C constructs. MSVC
is now a lot better and, for example, supports the fixed width types, so
"a conservative subset of C89" is maybe too restrictive.

On Tuesday, 19 April 2022 at 16:47:49 UTC+1, james...@alumni.caltech.edu wrote:
> On 4/18/22 20:32, Andrey Tarasevich wrote:
> ...
> > When code does not compile in Visual Studio it is effectively useless.
> > Compatibility with Visual Studio is a hard requirement for all C and
> > C++ code in professional world.
> I've spent a quarter century as a professional computer programmer
> working on projects where compatibility with Visual Studios was not a
> requirement, or even a priority. Our code was required to conform to the
> C standard. We were allowed to assume POSIX conformance (though we made
> little use of that fact other than the fact that our build scripts were
> intended for POSIX sh, and our make files were intended for the POSIX
> make utility). We were otherwise prohibited from writing
> platform-specific code (not even if protected by #if* directives based
> upon platform-specific macros) - that includes depending upon gcc
> extensions.
>
I've done both. Currently my code targets clang on Mac and MSVC on
Windows. There's the occasional conditional directive, but fewer than you
might imagine, and mostly because the GUI routines are a pixel out.
But for my PhD Windows compatibility was not required. However I use
quite a few of the routines I developed for general-purpose use on
Windows.

On 4/19/2022 5:48 PM, Malcolm McLean wrote:
> On Tuesday, 19 April 2022 at 16:40:11 UTC+1, Manfred wrote:
>> On 4/19/2022 4:43 PM, Malcolm McLean wrote:
>>> On Tuesday, 19 April 2022 at 15:07:48 UTC+1, Scott Lurndal wrote:
>>>> Andrey Tarasevich <andreyta...@hotmail.com> writes:
>>>>> On 4/18/2022 9:44 AM, Jack Lemmon wrote:
>>>>
>>>>> When code does not compile in Visual Studio it is effectively useless.
>>>>> Compatibility with Visual Studio is a hard requirement for all C and C++
>>>>> code in professional world.
>>>> Now that's funny. I've been programming "in the professional world",
>>>> in C and C++ for forty years, and Visual Studio has _never_ been part
>>>> of that process. It's been considered a toy compiler by most.
>>>>
>>> It's not a good C compiler. But it's the most realistic option for compiling
>>> Windows programs, and there are often good reasons for writing programs
>>> to run on Windows.
>>> If you stick to a conservative subset of C89, you should be OK. So MSVC
>>> is a reason for sticking to that conservative subset.
>> I'd even say that /if/ you need to target Windows, it's probably the
>> best compiler for the job, in the sense that the benefit of platform
>> compatibility wins over the cost of lower standard compliance.
>>
>> However, the main fact is that MSVC is primarily designed as a C++
>> compiler, and even if, as you say, there are good reason to write
>> programs for Windows, most often these are C++ programs, rather than C.
>>
> If you know that the program will be targetted at Windows, and never
> run on any other platform, then generally you should go for C++ or C sharp,
> because of better compiler support.
> But if you are writing a general purpose routine, it will be easier to integrate
> with other code if it is in C. It can be given C++, C sharp, Objective C, or
> Python bindings quite easily. But it does need to compile under Visual C.
> So you should be quite conservative in your choice of C constructs. MSVC
> is now a lot better and, for example, supports the fixed width types, so
> "a conservative subset of C89" is maybe too restrictive.

Yes, that's especially true for libraries, for which portability is a
major requirement. C is definitely a common choice there, and you are
right that with C89 you're most probably good with MSVC too.

You were mentioning "programs", which made my comment drift towards end
user applications.
(C# is a very different animal, but that's out of topic here)

On 18/04/2022 17:44, Jack Lemmon wrote:
> char get_char(const char *format, ...) __attribute__((format(printf, 1,
> 2)));
>
> I downloaded a free library file from this link:
> <https://github.com/cs50/libcs50/releases>
>
> But when I try to compile it, it faults at line 58 and other lines
> containing attribute world. So what exactly is likely to be wrong with it.?
> The library was created by Harvard uni for students to learn C
> programming so it must work on a Windows system using visual Studio, but
> it doesn't. What changes should I make to make it work?
>
>
I downloaded the source code from the link you provided and I ran a test
program in Visual Studio 2022. Initially, I got an error but when I
changed the configuration to look like in this picture
<https://i.imgur.com/m4Kxz6F.png>, it compiled and ran just fine as far
as I can tell!!!. I haven't tried all the functions given in the file
but they should all work if you know what they are supposed to do. I
tried just one to get a string from the command prompt and the test
program is this:

#include <stdio.h>
#include "cs50.h"

// For command Line use this:
// clang -o Prog.exe program.c cs50.c
// gcc -o Prog.exe program.c cs50.c

int main(void)
{ string name = get_string("What's your name? ");
printf("Hello, %s", name);
return 0;
}

You will need to install LLVM from Microsoft so if you want to know how
this is done then please post back. The Official site for LLVM only
gives compiled binaries in zip form so you can't just unzip the file and
expect Visual Studio to know about it. It needs to be installed so that
Windows can recognize the location.

On Tuesday, April 19, 2022 at 1:44:01 PM UTC-3, Sams Lara wrote:
> On 18/04/2022 17:44, Jack Lemmon wrote:
> > char get_char(const char *format, ...) __attribute__((format(printf, 1,
> > 2)));
> >
> > I downloaded a free library file from this link:
> > <https://github.com/cs50/libcs50/releases>
> >
> > But when I try to compile it, it faults at line 58 and other lines
> > containing attribute world. So what exactly is likely to be wrong with it.?
> > The library was created by Harvard uni for students to learn C
> > programming so it must work on a Windows system using visual Studio, but
> > it doesn't. What changes should I make to make it work?
> >
> >
> I downloaded the source code from the link you provided and I ran a test
> program in Visual Studio 2022. Initially, I got an error but when I
> changed the configuration to look like in this picture
> <https://i.imgur.com/m4Kxz6F.png>, it compiled and ran just fine as far
> as I can tell!!!. I haven't tried all the functions given in the file
> but they should all work if you know what they are supposed to do. I
> tried just one to get a string from the command prompt and the test
> program is this:
>
> #include <stdio.h>
> #include "cs50.h"
>
> // For command Line use this:
> // clang -o Prog.exe program.c cs50.c
> // gcc -o Prog.exe program.c cs50.c
>
> int main(void)
> {
> string name = get_string("What's your name? ");
> printf("Hello, %s", name);
> return 0;
> }
>
> You will need to install LLVM from Microsoft so if you want to know how
> this is done then please post back. The Official site for LLVM only
> gives compiled binaries in zip form so you can't just unzip the file and
> expect Visual Studio to know about it. It needs to be installed so that
> Windows can recognize the location.

Visual Studio has good suport for C99 and C11. You must change the settings.
No need to use clang but it is good to have.

On 4/19/2022 7:07 AM, Scott Lurndal wrote:
> Andrey Tarasevich <andreytarasevich@hotmail.com> writes:
>> On 4/18/2022 9:44 AM, Jack Lemmon wrote:
>
>> When code does not compile in Visual Studio it is effectively useless.
>> Compatibility with Visual Studio is a hard requirement for all C and C++
>> code in professional world.
>
> Now that's funny. I've been programming "in the professional world",
> in C and C++ for forty years, and Visual Studio has _never_ been part
> of that process. It's been considered a toy compiler by most.

Um...

I while ago some guy in a C and C++ programming I had to post a piece of
C++ code that used a lambda expression. Some old-timer guy responded to
my post with something passive-aggressive along the lines of: "This is
bogus. I've been professionally programming in C for 40 years, but I
have never seen this syntax". I was genuinely stopped in my tracks for a
minute at least for a minute at least, speechless: so many things are
completely off in it.

Your post above conveys pretty much the same dumbfounding feel to me.

As I has already stated previously, aside from some understandable niche
areas, which amount to no more than mere statistical anomalies,
everything in professional programming world is done in Visual Studio,
regardless of the target platform. But since we are talking more about
the compilers, than about the development environments, what today's
state of affairs clearly demonstrated is that at certain level of
complexity community-developed software is still incapable of competing
with commercially-backed software. It is probably more about C++ that C,
but today Microsoft C and C++ compilers clearly dominate as the highest
quality industrial-grade compilers, with Clang being close second. And
the catastrophic decay of GCC is probably the most telling sign of this
situation. That one survives (just barely) purely on half-dead legacy
code and the inertia of low-quality educational usage, as in the example
above.

Yes, there are people who manage to get by using just any compiler, but
(and I apologize for re-using the analogy I already used more than once)
that is like saying that some people ride a mono-cycle to work. Yes,
such people exist and I actually know a professional programmer who
routinely rides to work on a mono-cycle.

--
Best regards,
Andrey Tarasevich

On 4/19/2022 7:43 AM, Malcolm McLean wrote:
> On Tuesday, 19 April 2022 at 15:07:48 UTC+1, Scott Lurndal wrote:
>> Andrey Tarasevich <andreyta...@hotmail.com> writes:
>>> On 4/18/2022 9:44 AM, Jack Lemmon wrote:
>>
>>> When code does not compile in Visual Studio it is effectively useless.
>>> Compatibility with Visual Studio is a hard requirement for all C and C++
>>> code in professional world.
>> Now that's funny. I've been programming "in the professional world",
>> in C and C++ for forty years, and Visual Studio has _never_ been part
>> of that process. It's been considered a toy compiler by most.
>>
> It's not a good C compiler. But it's the most realistic option for compiling
> Windows programs, and there are often good reasons for writing programs
> to run on Windows.

All programs are written for Windows initially, since regardless of the
intended target platform, all everyday development and debugging is done
under Windows in Visual Studio anyway. For example, nobody in their
right mind develops Linux applications under the actual Linux (again,
aside from niche areas and... well... weirdos).

As I said before, any C and C++ library, targeting any platform, has to
be compatible with Visual Studio compilers to have a chance. Without
such compatibility, the library will never take off simply because
people won't be able to use it in their everyday development.

>> If you stick to a conservative subset of C89, you should be OK. So MSVC
>> is a reason for sticking to that conservative subset.

That sounds like a typical internet-grade lore.

With "classic" C things are simple: as C89/90 compiler Microsoft C
compiler has always served as universally recognized industry standard.

Moreover, somewhat surprisingly Microsoft C compiler has been recognized
as one of the best C99 compilers for quote a while (since 2013?), even
though at that time C99 support was not officially acknowledged by
Microsoft. Despite the fact that C99 support was not complete back then
(~90%?), it kinda "defined" the "meaningful subset" of C99 people
actually cared about. The primary reason why people shied away from VLA
and `_Generic` was lack of support in Microsoft subset of C99. Now, when
C99 support is official in Microsoft C compiler that era is over.

Bizarre references to some "conservative subsets" will only make you
look like a newbie who "wants to belong" and tries to use big-boy's
lingo, but only embarrasses himself instead.

--
Best regards,
Andrey Tarasevich

Andrey Tarasevich <andreytarasevich@hotmail.com> writes:
[...]
> All programs are written for Windows initially, since regardless of
> the intended target platform, all everyday development and debugging
> is done under Windows in Visual Studio anyway. For example, nobody in
> their right mind develops Linux applications under the actual Linux
> (again, aside from niche areas and... well... weirdos).

I don't know whether you're trolling or mistaken, but that's simply not
true. If you actually believe that, consider that other people might
have experiences that differ from yours.

In my previous job, for example, I worked on Linux, targeting embedded
Linux, using gcc, and I didn't even have a Windows machine at work.

[...]

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

In article <t3mn08$qtn$1@gioia.aioe.org>, Manfred <noname@add.invalid> wrote:
....
>(C# is a very different animal, but that's off topic here)

As is C++, Fortran, and BAL.

--

Prayer has no place in the public schools, just like facts
have no place in organized religion.
-- Superintendent Chalmers