Embarcadero C/C++ Compiler available

[Mel Smith]

Hi:

If you would like to test/try out the new 'Borland' C/C++ Compiler
(from Embarcadero) BCC 6.6.0, there is a link below.

This console-only compiler was extracted from the C++ Builder package
XE4

http://www.mediafire.com/?655px1guh9z5isy

--
Mel Smith

[Keith Thompson]

"Mel Smith" <med_cuto...@aol.com> writes:
> If you would like to test/try out the new 'Borland' C/C++ Compiler
> (from Embarcadero) BCC 6.6.0, there is a link below.
>
> This console-only compiler was extracted from the C++ Builder package
> XE4
>

> http://www.mediafire.com/?[DELETED]

Embarcadero offers a free 30-day trial of C++ Builder, which appears not
to be free software. I believe the above link is a copyright violation.

And I see no mention of C on their web page (perhaps I just didn't find
it), so it's not even clear this is topical.

--
Keith Thompson (The_Other_Keith) ks...@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"

[Mel Smith]

Keith said:
> Embarcadero offers a free 30-day trial of C++ Builder, which appears not
> to be free software. I believe the above link is a copyright violation.

BullPucky ! Embarcadero is aware of this, and encourages it.

>
> And I see no mention of C on their web page (perhaps I just didn't find
> it)

No, its not advertisedf, just provided.

>, so it's not even clear this is topical.

a C-Language compiler is *not topical* ?!?

In my own news group, thoudsands of us use their BCC offerings:
including BCC5.8, BCC 6.5, and BCC 6.6.0

We don't sell it, only use it to compile our apps.


-Mel

[Keith Thompson]

"Mel Smith" <med_cuto...@aol.com> writes:
> Keith said:
>> Embarcadero offers a free 30-day trial of C++ Builder, which appears not
>> to be free software. I believe the above link is a copyright violation.
>
> BullPucky ! Embarcadero is aware of this, and encourages it.

Perhaps you could provide some evidence of that. (That doesn't imply
that I disbelieve you.) If they're willing to allow their compiler to
be distributed for free, I wonder why they don't just do it themselves.
Or do they? If so, I'd frankly rather download it from their site than
from mediafire.com in a proprietary format (it's a .rar file).

>> And I see no mention of C on their web page (perhaps I just didn't find
>> it)
>
> No, its not advertisedf, just provided.
>
>>, so it's not even clear this is topical.
>
> a C-Language compiler is *not topical* ?!?

As I said, it *appeared* from the information I found in a cursory
examination of embarcadero.com to be just a C++ compiler. I just looked
again, and http://www.embarcadero.com/products/cbuilder says they
support both C and C++ -- including the C11 and C++11 standards. The
existence of a C compiler that supports (how well?) the C11 standard is
interesting news.

> In my own news group, thoudsands of us use their BCC offerings:
> including BCC5.8, BCC 6.5, and BCC 6.6.0

What is your "own news group"?

> We don't sell it, only use it to compile our apps.

Whether you sell it or not is not particularly relevant.

[Rich Webb]

On Fri, 03 May 2013 18:29:33 -0700, Keith Thompson <ks...@mib.org>
wrote:

>"Mel Smith" <med_cuto...@aol.com> writes:
>> Keith said:
>>> Embarcadero offers a free 30-day trial of C++ Builder, which appears not
>>> to be free software. I believe the above link is a copyright violation.
>>
>> BullPucky ! Embarcadero is aware of this, and encourages it.
>
>Perhaps you could provide some evidence of that. (That doesn't imply
>that I disbelieve you.) If they're willing to allow their compiler to
>be distributed for free, I wonder why they don't just do it themselves.
>Or do they? If so, I'd frankly rather download it from their site than
>from mediafire.com in a proprietary format (it's a .rar file).

They *do* provide a legitimate d/l of their "classic" bcb 5.5 C/C++
command-line compiler. Of their current release? Highly doubtful. Most
likely a rip-off.

[Luuk]

On 03-05-2013 18:40, Mel Smith wrote:
> Hi:
>
> If you would like to test/try out the new 'Borland' C/C++ Compiler
> (from Embarcadero) BCC 6.6.0, there is a link below.
>
> This console-only compiler was extracted from the C++ Builder package
> XE4
>

> http://....
>


Abstract: The free download version of the Borland C++ Compiler version
5.5 is now available.:
http://edn.embarcadero.com/article/20633

C++ Compiler 5.5
C++Builder Compiler (bcc compiler) free download. See the file
bcb5tool.hlp in the Help directory for complete instructions on using
the C++Builder Compiler and Command Line Tools. We recommend downloading
the C++Builder or RAD Studio Trial editions instead to get the latest
compilers for Windows and Mac with a complete IDE experience.
https://downloads.embarcadero.com/free/c_builder

[Malcolm McLean]

On Saturday, May 4, 2013 2:29:33 AM UTC+1, Keith Thompson wrote:
> "Mel Smith" <med_cuto...@aol.com> writes:
>
>

> As I said, it *appeared* from the information I found in a cursory
> examination of embarcadero.com to be just a C++ compiler.
>

I don't think it's possible to get a C++ compiler which won't compile files with
a .c extension as C. It would be possible to write one, of course, but the
extra effort involved in supporting at least some dialect of C is so small
that it would be a pointless exercise.

[Kenny McCormack]

In article <c6f1ece7-e927-47d9...@googlegroups.com>,

I agree, but you must keep in mind that *most* of Keith Thompson's posts are
pointless exercises. Keith excels in pointless exercises [*].

Of course, one might also say that of the Usenet in general, but it, at least
among (nominally) technical groups, CLC and Keith Thompson are standout examples.

[*] Such as constantly reminding us that C and C++ are distinct languages, and
generally pretending that they are completely unrelated to each other - as
different as, say, C and Fortran.

--
"The anti-regulation business ethos is based on the charmingly naive notion
that people will not do unspeakable things for money." - Dana Carpender

Quoted by Paul Ciszek (pciszek at panix dot com). But what I want to know
is why is this diet/low-carb food author doing making pithy political/economic
statements?

Nevertheless, the above quote is dead-on, because, the thing is - business
in one breath tells us they don't need to be regulated (which is to say:
that they can morally self-regulate), then in the next breath tells us that
corporations are amoral entities which have no obligations to anyone except
their officers and shareholders, then in the next breath they tell us they
don't need to be regulated (that they can morally self-regulate) ...

[Keith Thompson]

Maybe. Microsoft has certainly decided not to devote much further
effort to C. Their Visual Studio supports only C (plus a very few C99
features), and that's probably only because it already had that support,
since C is older than C++. I can imagine some vendor developing a new
C++ compiler from scratch and not bothering with C support.

But I don't know of any that have actually done so.

[Malcolm McLean]

On Saturday, May 4, 2013 9:01:24 PM UTC+1, Keith Thompson wrote:
> Malcolm McLean <malcolm...@btinternet.com> writes:
>
> > On Saturday, May 4, 2013 2:29:33 AM UTC+1, Keith Thompson wrote:
>
>
> Maybe. Microsoft has certainly decided not to devote much further
> effort to C. Their Visual Studio supports only C (plus a very few C99
> features), and that's probably only because it already had that support,
> since C is older than C++. I can imagine some vendor developing a new
> C++ compiler from scratch and not bothering with C support.
>

Microsoft seem to have a policy of deliberately breaking legacy source
(but not legacy executables). However they daredn't do that to standard
C, because too many fundamental routines which applications developers
rely on and don't have the skills to write themselves are written in C.

[glen herrmannsfeldt]

One thing that always bothered me about unix, as compared to some
DEC systems like VMS is the way it treats file extensions.

For VMS commands, most have a default extension, but will work fine
if you supply a different one.

One that always surprised me was the PRINT command default of .LIS,
though I rarely named my files that way, even if I did plan to PRINT
them.

Having not tried recently, I would expect a VMS C++ compiler to happily
compile C++ code with a .c extension, and the C compiler to compile
C code with a .cpp extension. (I don't remember if + is a legal
character in VMS file names or extensions.)

-- glen

[Vincenzo Mercuri]

On 03/05/2013 18:40, Mel Smith wrote:
[..]

> This console-only compiler was extracted from the C++ Builder package
> XE4

[..]

http://edn.embarcadero.com/article/43066


--
Vincenzo Mercuri

[Vincenzo Mercuri]

On 05/05/2013 03:24, Vincenzo Mercuri wrote:
> On 03/05/2013 18:40, Mel Smith wrote:
> [..]
>> This console-only compiler was extracted from the C++ Builder
>> package
>> XE4
> [..]
>
> http://edn.embarcadero.com/article/43066
>
>

$2.4 [..] The Command Line Compiler shall not be considered
a �redistributable�.

--
Vincenzo Mercuri

[Tim Prince]

The tradition (from some flavor of unix?) embodied in gnu compilers has
spread. By default, language is chosen according to file extension,
with options provided to over-ride that selection.
People trip up all the time over the way .cpp changes the C compiler to
C++ but the change doesn't carry over to the link step.
Note the use of
gcc -E -P -x c -traditional file.whatever
to invoke cpp translation of source files for other languages in
accordance with C89.
Is this a small inconsistency to use -traditional to mean C89 here
(otherwise defaulting to C99), where the compiler itself uses other
options for that purpose, so the net default is C99 pre-processing fed
to c89 plus gnu89 extensions?

[Keith Thompson]

Tim Prince <tpr...@nospamcomputer.org> writes:
[...]

> The tradition (from some flavor of unix?) embodied in gnu compilers has
> spread. By default, language is chosen according to file extension,
> with options provided to over-ride that selection.
> People trip up all the time over the way .cpp changes the C compiler to
> C++ but the change doesn't carry over to the link step.
> Note the use of
> gcc -E -P -x c -traditional file.whatever
> to invoke cpp translation of source files for other languages in
> accordance with C89.
> Is this a small inconsistency to use -traditional to mean C89 here
> (otherwise defaulting to C99), where the compiler itself uses other
> options for that purpose, so the net default is C99 pre-processing fed
> to c89 plus gnu89 extensions?

gcc's "traditional" option causes the preprocessor to behave in a
pre-ANSI manner, not as C89. See the GNU cpp documentation for details.
Defining "pre-ANSI" can be non-trivial since, well, there was no
standard. The "traditional" option is no longer supported without "-E"
(which says to invoke only the preprocessor)

[Jorgen Grahn]

On Sat, 2013-05-04, glen herrmannsfeldt wrote:
> Malcolm McLean <malcolm...@btinternet.com> wrote:

...

>> I don't think it's possible to get a C++ compiler which won't compile files with
>> a .c extension as C. It would be possible to write one, of course, but the
>> extra effort involved in supporting at least some dialect of C is so small
>> that it would be a pointless exercise.
>
> One thing that always bothered me about unix, as compared to some
> DEC systems like VMS is the way it treats file extensions.

But Unix /doesn't/ treat file extensions, most of the time.

Compilers are an exception. Perhaps because Make (another exception)
relies on them anyway, so you have foo.c, foo.o and libfoo.a and so on.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[Ken Brody]

On 5/4/2013 4:29 PM, Malcolm McLean wrote:
[...]

> Microsoft seem to have a policy of deliberately breaking legacy source
> (but not legacy executables). However they daredn't do that to standard
> C, because too many fundamental routines which applications developers
> rely on and don't have the skills to write themselves are written in C.

They do, however, like to give warnings about "unsafe" and "deprecated"
functions, and suggest that you change to, not the ANSI-standard "safe"
version, but the MS-specific "safe" version.

For example:

warning C4996: 'fopen': This function or variable may be unsafe.
Consider using fopen_s instead.

(Although some forum comments I saw say that fopen_s() is now part of C11, I
can't confirm/refute that statement.)

--
Kenneth Brody

[James Kuyper]

It is indeed in C11, section K.3.5.2.1. The functions described in Annex
K only need to be defined on implementations that choose to pre#define
__STDC_LIB_EXT1__.

[Thomas Richter]

Am 10.05.2013 16:32, schrieb James Kuyper:

>>
>> They do, however, like to give warnings about "unsafe" and "deprecated"
>> functions, and suggest that you change to, not the ANSI-standard "safe"
>> version, but the MS-specific "safe" version.
>>
>> For example:
>>
>> warning C4996: 'fopen': This function or variable may be unsafe.
>> Consider using fopen_s instead.
>>
>> (Although some forum comments I saw say that fopen_s() is now part of C11, I
>> can't confirm/refute that statement.)
>
> It is indeed in C11, section K.3.5.2.1. The functions described in Annex
> K only need to be defined on implementations that choose to pre#define
> __STDC_LIB_EXT1__.

Sorry for getting off-topic, but could anyone explain me what on fopen()
might be insecure? It does not write to its arguments, expects just
const strings as arguments it has to parse, so how could one use fopen
in a way that breaches security that is not available with fopen_s()?
Ok, shoot yourself in the foot by potentially writing to files you want
to (or need to) keep, but that's not different from fopen_s(), is it?

I do see the point for sprintf, for example.

[Kenny McCormack]

In article <kmjfoo$7t4$1...@news2.informatik.uni-stuttgart.de>,
Thomas Richter <th...@math.tu-berlin.de> wrote:
...

>Sorry for getting off-topic, but could anyone explain me what on fopen()
>might be insecure? It does not write to its arguments, expects just
>const strings as arguments it has to parse, so how could one use fopen
>in a way that breaches security that is not available with fopen_s()?
>Ok, shoot yourself in the foot by potentially writing to files you want
>to (or need to) keep, but that's not different from fopen_s(), is it?
>
>I do see the point for sprintf, for example.
>

I think the idea is that any function that takes a string argument has to also
include a length parameter for that string arg. Essentially, replacing C-style
strings (which are inherently unsafe) with Pascal-style strings. Well, not
really, since the length parameter would specify the max length of the string,
not the actual length (IIRC).

Because otherwise, an evil user could supply a non-null-terminated "string"
(have to put that in scare quotes, else Kiki will have a heart attack), and
thus invoke UB. And then God knows what could happen...

[James Kuyper]

On 05/10/2013 02:54 PM, Thomas Richter wrote:
> Am 10.05.2013 16:32, schrieb James Kuyper:
>
>>>
>>> They do, however, like to give warnings about "unsafe" and "deprecated"
>>> functions, and suggest that you change to, not the ANSI-standard "safe"
>>> version, but the MS-specific "safe" version.
>>>
>>> For example:
>>>
>>> warning C4996: 'fopen': This function or variable may be unsafe.
>>> Consider using fopen_s instead.
>>>
>>> (Although some forum comments I saw say that fopen_s() is now part of C11, I
>>> can't confirm/refute that statement.)
>>
>> It is indeed in C11, section K.3.5.2.1. The functions described in Annex
>> K only need to be defined on implementations that choose to pre#define
>> __STDC_LIB_EXT1__.
>
> Sorry for getting off-topic, but could anyone explain me what on fopen()

> might be insecure? ...

I think, at least in this case, that it's more about safety than about
security.

> ...It does not write to its arguments, expects just

> const strings as arguments it has to parse, so how could one use fopen
> in a way that breaches security that is not available with fopen_s()?
> Ok, shoot yourself in the foot by potentially writing to files you want
> to (or need to) keep, but that's not different from fopen_s(), is it?

Here's the declaration for fopen():
FILE *fopen(const char * restrict filename,
const char * restrict mode);

Here's the declaration for fopen_s():
errno_t fopen_s(FILE * restrict * restrict streamptr,
const char * restrict filename,
const char * restrict mode);

There are two mistakes you can make when calling fopen() that fopen_s()
protects against:

FILE *file = fopen(NULL, inmode);

This code has undefined behavior "by the omission of any explicit
definition of behavior" (4p2), since the description of what fopen()
does with its filename argument (7.21.5.3p2) is meaningless when that
argument is a null pointer. The corresponding code using fopen_s() has
defined behavior: it will make no attempt to open a file, *streamptr
will be set to a null pointer value (K.3.5.2.1p2,3), and fopen_s() will
return a non-zero value. This strikes me as a good idea.

The second mistake would be something like the following:

fopen(outfilename, outmode);

This code opens a file without having any way to do anything with it,
including close it. The corresponding code using fopen_s() would be:

FILE *outfile;
fopen_s(&outfile, outfilename, &outmode);

You can still discard outfile immediately, producing the same net
result, but the necessity of creating a valid pointer to a FILE* object
makes it harder to make that particular error accidentally.

I don't see any value in adding a level of indirection to the mode. All
is does is create new ways for the function to fail: if the third
argument is null, it fails with defined behavior: no attempt will be
made to open the file, and *streamptr will be set to a null pointer
value, and fopen_s(). However, because of the restrict qualifiers, if
the third argument points at memory which overlaps that pointed at by
streamptr, filename, the behavior is undefined; a situation that
couldn't meaningfully be a problem with fopen().

[glen herrmannsfeldt]

Kenny McCormack <gaz...@shell.xmission.com> wrote:
> In article <kmjfoo$7t4$1...@news2.informatik.uni-stuttgart.de>,
(snip)

>>Sorry for getting off-topic, but could anyone explain me what on fopen()
>>might be insecure? It does not write to its arguments, expects just
>>const strings as arguments it has to parse, so how could one use fopen
>>in a way that breaches security that is not available with fopen_s()?
>>Ok, shoot yourself in the foot by potentially writing to files you want
>>to (or need to) keep, but that's not different from fopen_s(), is it?

(snip)

> I think the idea is that any function that takes a string argument has to also
> include a length parameter for that string arg. Essentially, replacing C-style
> strings (which are inherently unsafe) with Pascal-style strings. Well, not
> really, since the length parameter would specify the max length of the string,
> not the actual length (IIRC).

It you know the length, then just stuff in '\0' as the last character.
You might cut off the end of the file name, but you are sure that there
is at least one in there.

-- glen

[James Kuyper]

On 05/10/2013 03:49 PM, glen herrmannsfeldt wrote:
> Kenny McCormack <gaz...@shell.xmission.com> wrote:
>> In article <kmjfoo$7t4$1...@news2.informatik.uni-stuttgart.de>,
> (snip)
>>> Sorry for getting off-topic, but could anyone explain me what on fopen()
>>> might be insecure? It does not write to its arguments, expects just
>>> const strings as arguments it has to parse, so how could one use fopen
>>> in a way that breaches security that is not available with fopen_s()?
>>> Ok, shoot yourself in the foot by potentially writing to files you want
>>> to (or need to) keep, but that's not different from fopen_s(), is it?
>
> (snip)
>> I think the idea is that any function that takes a string argument has to also
>> include a length parameter for that string arg.

The new functions have new length parameters only for pointers to the
first element of arrays that they write to, and it doesn't matter
whether those arrays contain strings either before or after the function
is called (for instance, memmove_s() takes a length parameter).
fopen_s() has no such arguments, so it doesn't take any length parameters.

[James Kuyper]

Several parts of my previous message (which I just cancelled, but you
may still be able to see it) made no sense due to a stupid thinking
error about the mode argument of fopen(). Please ignore that version, in
favor of this one:

On 05/10/2013 02:54 PM, Thomas Richter wrote:

> Am 10.05.2013 16:32, schrieb James Kuyper:
>
>>>
>>> They do, however, like to give warnings about "unsafe" and "deprecated"
>>> functions, and suggest that you change to, not the ANSI-standard "safe"
>>> version, but the MS-specific "safe" version.
>>>
>>> For example:
>>>
>>> warning C4996: 'fopen': This function or variable may be unsafe.
>>> Consider using fopen_s instead.
>>>
>>> (Although some forum comments I saw say that fopen_s() is now part of C11, I
>>> can't confirm/refute that statement.)
>>
>> It is indeed in C11, section K.3.5.2.1. The functions described in Annex
>> K only need to be defined on implementations that choose to pre#define
>> __STDC_LIB_EXT1__.
>
> Sorry for getting off-topic, but could anyone explain me what on fopen()

> might be insecure? ...

I think, at least in this case, that it's more about safety than about
security.

> ...It does not write to its arguments, expects just

> const strings as arguments it has to parse, so how could one use fopen
> in a way that breaches security that is not available with fopen_s()?
> Ok, shoot yourself in the foot by potentially writing to files you want
> to (or need to) keep, but that's not different from fopen_s(), is it?

Here's the declaration for fopen():
FILE *fopen(const char * restrict filename,
const char * restrict mode);

Here's the declaration for fopen_s():
errno_t fopen_s(FILE * restrict * restrict streamptr,
const char * restrict filename,
const char * restrict mode);

There are three mistakes you can make when calling fopen() that
fopen_s() protects against:

FILE *infile = fopen(NULL, inmode);
FILE *outfile = fopen(outfilename, NULL);

These calls have undefined behavior "by the omission of any explicit

definition of behavior" (4p2), since the description of what fopen()

does with its filename and mode arguments (7.21.5.3p2) is meaningless
when either of those arguments is a null pointer. The corresponding code

using fopen_s() has defined behavior: it will make no attempt to open a
file, *streamptr will be set to a null pointer value (K.3.5.2.1p2,3),
and fopen_s() will return a non-zero value. This strikes me as a good idea.

The third mistake would be something like the following:

fopen(outfilename, outmode);

This code opens a file without having any way to do anything with it,
including close it. The corresponding code using fopen_s() would be:

FILE *outfile;

fopen_s(&outfile, outfilename, outmode);

[Keith Thompson]

See N1570 (available at
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf) section
K.3.5.2.1, for a description of fopen_s.

The differences from fopen are:
- It returns an errno_t result rather than a FILE*, and "returns" the
FILE* via a pointer-to-pointer parameter.
- It does some stuff with "runtime-constraint violations", which I'm too
lazy to look up and summarize at the moment.
- The mode string can optionally be preceded by a 'u' character.
Without 'u', when creating a file, the permissions are set to prevent
other uses on the system from accessing it "to the extent that the
underlying system supports it"; with 'u', it uses default permissions.