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

Groups > comp.lang.c > #140033 > unrolled thread

compiling all c code

Back to article view | Back to comp.lang.c

Contents

  compiling all c code fiziqs@gmail.com - 2019-01-20 14:51 -0800
    Re: compiling all c code Richard Damon <Richard@Damon-Family.org> - 2019-01-20 18:41 -0500
    Re: compiling all c code gazelle@shell.xmission.com (Kenny McCormack) - 2019-01-20 23:42 +0000
    Re: compiling all c code Geoff <geoff@invalid.invalid> - 2019-01-20 16:44 -0800
      Re: compiling all c code fiziqs@gmail.com - 2019-01-21 02:36 -0800
        Re: compiling [old] c code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-01-21 12:20 +0000
          Re: compiling [old] c code fiziqs@gmail.com - 2019-01-21 04:58 -0800
            Re: compiling [old] c code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-01-21 18:33 +0000
              Re: compiling [old] c code fir <profesor.fir@gmail.com> - 2019-01-22 04:21 -0800
                Re: compiling [old] c code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-01-22 16:46 +0000
                  Re: compiling [old] c code fir <profesor.fir@gmail.com> - 2019-01-22 10:35 -0800
                    Re: compiling [old] c code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-01-22 22:45 +0000
                      Re: compiling [old] c code fir <profesor.fir@gmail.com> - 2019-01-22 14:58 -0800
                        Re: compiling [old] c code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-01-23 02:12 +0000
                          Re: compiling [old] c code fir <profesor.fir@gmail.com> - 2019-01-23 00:59 -0800
          Re: compiling [old] c code fir <profesor.fir@gmail.com> - 2019-01-22 03:34 -0800
            Re: compiling [old] c code fir <profesor.fir@gmail.com> - 2019-01-22 04:08 -0800
        Re: compiling all c code Keith Thompson <kst-u@mib.org> - 2019-01-21 14:23 -0800

#140033 — compiling all c code

Dear All,

I tried to compile a bit of code from the original Unix source and ran into the following problem:
they defined a "generic pointer type" ptr (actually it is a typedef), and pointers are casted to this. Also ones for structs.
Now, gcc does not accept the -> for such pointers.
Is there some way (e.g., compiler option) to get around this, or the only way is to look up for all these what kind of structure they refer to, and change their type?

Thanks a lot in advance.

[toc] | [next] | [standalone]

#140035

On 1/20/19 5:51 PM, fiziqs@gmail.com wrote:
> Dear All,
> 
> I tried to compile a bit of code from the original Unix source and ran into the following problem:
> they defined a "generic pointer type" ptr (actually it is a typedef), and pointers are casted to this. Also ones for structs.
> Now, gcc does not accept the -> for such pointers.
> Is there some way (e.g., compiler option) to get around this, or the only way is to look up for all these what kind of structure they refer to, and change their type?
> 
> Thanks a lot in advance.
> 

Very ancient proto-C put all structs members into a single address
space, and thus any (struct) pointer could be used to offset into a
structure to get that member. This is no longer valid C. Unless you have
a compiler that understands this ancient proto-c language as an option,
you are going to need to fix the code.

One option that might work is to gather all these struct definitions
into a single anonymous union, and then you just need to make pointers
that access any of these structures be pointers to that type of union.
That might be a bit less work.

[toc] | [prev] | [next] | [standalone]

#140036

In article <cbbefd94-59bf-489e-84c6-2633c289f119@googlegroups.com>,
 <fiziqs@gmail.com> wrote:
>Dear All,
>
>I tried to compile a bit of code from the original Unix source and ran into the
>following problem:
>they defined a "generic pointer type" ptr (actually it is a typedef), and
>pointers are casted to this. Also ones for structs.
>Now, gcc does not accept the -> for such pointers.
>Is there some way (e.g., compiler option) to get around this, or the only way is
>to look up for all these what kind of structure they refer to, and change their
>type?
>
>Thanks a lot in advance.

It would help if you posted some code, so we'd have some idea what you're
talking about.

-- 
Elect a clown, expect a circus.

[toc] | [prev] | [next] | [standalone]

#140042

On Sun, 20 Jan 2019 14:51:00 -0800 (PST), fiziqs@gmail.com wrote:

>Dear All,
>
>I tried to compile a bit of code from the original Unix source and ran into the following problem:

Can you post a link to this original Unix source so we can see what
vintage code you are talking about? Unix source is very ancient and
most C compilers probably can't compile it without special switches
to get them to conform to the dialect of C used at that time or else
extensive modification of those sources.

[toc] | [prev] | [next] | [standalone]

#140047

On Monday, January 21, 2019 at 1:45:03 AM UTC+1, Geoff wrote:
> On Sun, 20 Jan 2019 14:51:00 -0800 (PST), fiziqs@gmail.com wrote:
> 
> >Dear All,
> >
> >I tried to compile a bit of code from the original Unix source and ran into the following problem:
> 
> Can you post a link to this original Unix source so we can see what
> vintage code you are talking about? Unix source is very ancient and
> most C compilers probably can't compile it without special switches
> to get them to conform to the dialect of C used at that time or else
> extensive modification of those sources.

Actually, it was the EFL language, just to know if it is still possible to compile this language:
https://minnie.tuhs.org/cgi-bin/utree.pl?file=4.4BSD/usr/src/old/efl

And sorry, I made a typo in the topic title, I meant "old C code", not "all".

[toc] | [prev] | [next] | [standalone]

#140050 — Re: compiling [old] c code

fiziqs@gmail.com writes:

> On Monday, January 21, 2019 at 1:45:03 AM UTC+1, Geoff wrote:
>> On Sun, 20 Jan 2019 14:51:00 -0800 (PST), fiziqs@gmail.com wrote:
<snip>
>> >I tried to compile a bit of code from the original Unix source and
>> >ran into the following problem:
<snip>
> Actually, it was the EFL language, just to know if it is still
> possible to compile this language:
> https://minnie.tuhs.org/cgi-bin/utree.pl?file=4.4BSD/usr/src/old/efl

Is there a link that allows a directory to be downloaded?  It looks much
more tractable than the very old C I, and others, were thinking about.
The sources there are from about 1982 and look like normal K&R C.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#140054 — Re: compiling [old] c code

On Monday, January 21, 2019 at 1:21:02 PM UTC+1, Ben Bacarisse wrote:
> fiziqs@gmail.com writes:
> 
> > On Monday, January 21, 2019 at 1:45:03 AM UTC+1, Geoff wrote:
> >> On Sun, 20 Jan 2019 14:51:00 -0800 (PST), fiziqs@gmail.com wrote:
> <snip>
> >> >I tried to compile a bit of code from the original Unix source and
> >> >ran into the following problem:
> <snip>
> > Actually, it was the EFL language, just to know if it is still
> > possible to compile this language:
> > https://minnie.tuhs.org/cgi-bin/utree.pl?file=4.4BSD/usr/src/old/efl
> 
> Is there a link that allows a directory to be downloaded?  It looks much
> more tractable than the very old C I, and others, were thinking about.
> The sources there are from about 1982 and look like normal K&R C.
> 
> -- 
> Ben.

Only as part of:
https://www.tuhs.org/Archive/Distributions/UCB/4.4BSD-Alpha/src.tar.gz

[toc] | [prev] | [next] | [standalone]

#140068 — Re: compiling [old] c code

fiziqs@gmail.com writes:

> On Monday, January 21, 2019 at 1:21:02 PM UTC+1, Ben Bacarisse wrote:
>> fiziqs@gmail.com writes:
>> 
>> > On Monday, January 21, 2019 at 1:45:03 AM UTC+1, Geoff wrote:
>> >> On Sun, 20 Jan 2019 14:51:00 -0800 (PST), fiziqs@gmail.com wrote:
>> <snip>
>> >> >I tried to compile a bit of code from the original Unix source and
>> >> >ran into the following problem:
>> <snip>
>> > Actually, it was the EFL language, just to know if it is still
>> > possible to compile this language:
>> > https://minnie.tuhs.org/cgi-bin/utree.pl?file=4.4BSD/usr/src/old/efl
>> 
>> Is there a link that allows a directory to be downloaded?  It looks much
>> more tractable than the very old C I, and others, were thinking about.
>> The sources there are from about 1982 and look like normal K&R C.
>> 
> Only as part of:
> https://www.tuhs.org/Archive/Distributions/UCB/4.4BSD-Alpha/src.tar.gz

That's not quite the same (no Makefile for example) but I assume C the
sources are similar.

Despite the date (1982) it is very old C.  I think you will struggle to
get it through a modern compiler.

Apart form the "big union" idea that's already been mentioned, you coud
try a macro:

#define PTR(p, s) ((struct s *)(p))

and re-write things like

  ttype = t->vtype;

as

  ttype = PTR(t, varblock)->vtype;

You might even be able to automate this a bit by using something like
Perl to record what structs have what members.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#140080 — Re: compiling [old] c code

W dniu poniedziałek, 21 stycznia 2019 19:34:08 UTC+1 użytkownik Ben Bacarisse napisał:
> fiziqs@gmail.com writes:
> 
> > On Monday, January 21, 2019 at 1:21:02 PM UTC+1, Ben Bacarisse wrote:
> >> fiziqs@gmail.com writes:
> >> 
> >> > On Monday, January 21, 2019 at 1:45:03 AM UTC+1, Geoff wrote:
> >> >> On Sun, 20 Jan 2019 14:51:00 -0800 (PST), fiziqs@gmail.com wrote:
> >> <snip>
> >> >> >I tried to compile a bit of code from the original Unix source and
> >> >> >ran into the following problem:
> >> <snip>
> >> > Actually, it was the EFL language, just to know if it is still
> >> > possible to compile this language:
> >> > https://minnie.tuhs.org/cgi-bin/utree.pl?file=4.4BSD/usr/src/old/efl
> >> 
> >> Is there a link that allows a directory to be downloaded?  It looks much
> >> more tractable than the very old C I, and others, were thinking about.
> >> The sources there are from about 1982 and look like normal K&R C.
> >> 
> > Only as part of:
> > https://www.tuhs.org/Archive/Distributions/UCB/4.4BSD-Alpha/src.tar.gz
> 
> That's not quite the same (no Makefile for example) but I assume C the
> sources are similar.
> 
> Despite the date (1982) it is very old C.  I think you will struggle to
> get it through a modern compiler.
> 
> Apart form the "big union" idea that's already been mentioned, you coud
> try a macro:
> 
> #define PTR(p, s) ((struct s *)(p))
> 
> and re-write things like
> 
>   ttype = t->vtype;
> 
> as
> 
>   ttype = PTR(t, varblock)->vtype;
> 
> You might even be able to automate this a bit by using something like
> Perl to record what structs have what members.
> 

it seems to me that he dont need to rewrite field acceses only maybe
put 

ptr = (struct some*) ptr; //?

in thet few places

dont seem to be 2 much big work

[toc] | [prev] | [next] | [standalone]

#140091 — Re: compiling [old] c code

fir <profesor.fir@gmail.com> writes:

> W dniu poniedziałek, 21 stycznia 2019 19:34:08 UTC+1 użytkownik Ben Bacarisse napisał:
>> fiziqs@gmail.com writes:
>> 
>> > On Monday, January 21, 2019 at 1:21:02 PM UTC+1, Ben Bacarisse wrote:
>> >> fiziqs@gmail.com writes:
>> >> 
>> >> > On Monday, January 21, 2019 at 1:45:03 AM UTC+1, Geoff wrote:
>> >> >> On Sun, 20 Jan 2019 14:51:00 -0800 (PST), fiziqs@gmail.com wrote:
>> >> <snip>
>> >> >> >I tried to compile a bit of code from the original Unix source and
>> >> >> >ran into the following problem:
>> >> <snip>
>> >> > Actually, it was the EFL language, just to know if it is still
>> >> > possible to compile this language:
>> >> > https://minnie.tuhs.org/cgi-bin/utree.pl?file=4.4BSD/usr/src/old/efl
>> >> 
>> >> Is there a link that allows a directory to be downloaded?  It looks much
>> >> more tractable than the very old C I, and others, were thinking about.
>> >> The sources there are from about 1982 and look like normal K&R C.
>> >> 
>> > Only as part of:
>> > https://www.tuhs.org/Archive/Distributions/UCB/4.4BSD-Alpha/src.tar.gz
>> 
>> That's not quite the same (no Makefile for example) but I assume C the
>> sources are similar.
>> 
>> Despite the date (1982) it is very old C.  I think you will struggle to
>> get it through a modern compiler.
>> 
>> Apart form the "big union" idea that's already been mentioned, you coud
>> try a macro:
>> 
>> #define PTR(p, s) ((struct s *)(p))
>> 
>> and re-write things like
>> 
>>   ttype = t->vtype;
>> 
>> as
>> 
>>   ttype = PTR(t, varblock)->vtype;
>> 
>> You might even be able to automate this a bit by using something like
>> Perl to record what structs have what members.
>
> it seems to me that he dont need to rewrite field acceses only maybe
> put 
>
> ptr = (struct some*) ptr; //?
>
> in thet few places

This would be a constraint violation and yet would achieve nothing.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#140094 — Re: compiling [old] c code

W dniu wtorek, 22 stycznia 2019 17:46:35 UTC+1 użytkownik Ben Bacarisse napisał:
> fir <profesor.fir@gmail.com> writes:
> 
> > W dniu poniedziałek, 21 stycznia 2019 19:34:08 UTC+1 użytkownik Ben Bacarisse napisał:
> >> fiziqs@gmail.com writes:
> >> 
> >> > On Monday, January 21, 2019 at 1:21:02 PM UTC+1, Ben Bacarisse wrote:
> >> >> fiziqs@gmail.com writes:
> >> >> 
> >> >> > On Monday, January 21, 2019 at 1:45:03 AM UTC+1, Geoff wrote:
> >> >> >> On Sun, 20 Jan 2019 14:51:00 -0800 (PST), fiziqs@gmail.com wrote:
> >> >> <snip>
> >> >> >> >I tried to compile a bit of code from the original Unix source and
> >> >> >> >ran into the following problem:
> >> >> <snip>
> >> >> > Actually, it was the EFL language, just to know if it is still
> >> >> > possible to compile this language:
> >> >> > https://minnie.tuhs.org/cgi-bin/utree.pl?file=4.4BSD/usr/src/old/efl
> >> >> 
> >> >> Is there a link that allows a directory to be downloaded?  It looks much
> >> >> more tractable than the very old C I, and others, were thinking about.
> >> >> The sources there are from about 1982 and look like normal K&R C.
> >> >> 
> >> > Only as part of:
> >> > https://www.tuhs.org/Archive/Distributions/UCB/4.4BSD-Alpha/src.tar.gz
> >> 
> >> That's not quite the same (no Makefile for example) but I assume C the
> >> sources are similar.
> >> 
> >> Despite the date (1982) it is very old C.  I think you will struggle to
> >> get it through a modern compiler.
> >> 
> >> Apart form the "big union" idea that's already been mentioned, you coud
> >> try a macro:
> >> 
> >> #define PTR(p, s) ((struct s *)(p))
> >> 
> >> and re-write things like
> >> 
> >>   ttype = t->vtype;
> >> 
> >> as
> >> 
> >>   ttype = PTR(t, varblock)->vtype;
> >> 
> >> You might even be able to automate this a bit by using something like
> >> Perl to record what structs have what members.
> >
> > it seems to me that he dont need to rewrite field acceses only maybe
> > put 
> >
> > ptr = (struct some*) ptr; //?
> >
> > in thet few places
> 
> This would be a constraint violation and yet would achieve nothing.
> 
what do you mean? you cant cast pointer
on another type of pointer?

[toc] | [prev] | [next] | [standalone]

#140096 — Re: compiling [old] c code

fir <profesor.fir@gmail.com> writes:

> W dniu wtorek, 22 stycznia 2019 17:46:35 UTC+1 użytkownik Ben Bacarisse napisał:
>> fir <profesor.fir@gmail.com> writes:
>> 
>> > W dniu poniedziałek, 21 stycznia 2019 19:34:08 UTC+1 użytkownik Ben Bacarisse napisał:
<snip>
>> >> Apart form the "big union" idea that's already been mentioned, you coud
>> >> try a macro:
>> >> 
>> >> #define PTR(p, s) ((struct s *)(p))
>> >> 
>> >> and re-write things like
>> >> 
>> >>   ttype = t->vtype;
>> >> 
>> >> as
>> >> 
>> >>   ttype = PTR(t, varblock)->vtype;
>> >> 
>> >> You might even be able to automate this a bit by using something like
>> >> Perl to record what structs have what members.
>> >
>> > it seems to me that he dont need to rewrite field acceses only
>> > maybe put
>> >
>> > ptr = (struct some*) ptr; //?
>> >
>> > in thet few places
>> 
>> This would be a constraint violation and yet would achieve nothing.
>> 
> what do you mean? you cant cast pointer
> on another type of pointer?

ptr is of type int *.  Assigning a struct some * to an int * object is
an error.  C, however, does not really have errors -- it has situations
that compiler must report.  These are called constraint violations and
your assignment is an example of one.

Your suggestion does not achieve anything because it does not solve the
problem.  You can't access the struct member after the assignment any
more that you could before.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#140097 — Re: compiling [old] c code

W dniu wtorek, 22 stycznia 2019 23:45:50 UTC+1 użytkownik Ben Bacarisse napisał:
> fir <profesor.fir@gmail.com> writes:
> 
> > W dniu wtorek, 22 stycznia 2019 17:46:35 UTC+1 użytkownik Ben Bacarisse napisał:
> >> fir <profesor.fir@gmail.com> writes:
> >> 
> >> > W dniu poniedziałek, 21 stycznia 2019 19:34:08 UTC+1 użytkownik Ben Bacarisse napisał:
> <snip>
> >> >> Apart form the "big union" idea that's already been mentioned, you coud
> >> >> try a macro:
> >> >> 
> >> >> #define PTR(p, s) ((struct s *)(p))
> >> >> 
> >> >> and re-write things like
> >> >> 
> >> >>   ttype = t->vtype;
> >> >> 
> >> >> as
> >> >> 
> >> >>   ttype = PTR(t, varblock)->vtype;
> >> >> 
> >> >> You might even be able to automate this a bit by using something like
> >> >> Perl to record what structs have what members.
> >> >
> >> > it seems to me that he dont need to rewrite field acceses only
> >> > maybe put
> >> >
> >> > ptr = (struct some*) ptr; //?
> >> >
> >> > in thet few places
> >> 
> >> This would be a constraint violation and yet would achieve nothing.
> >> 
> > what do you mean? you cant cast pointer
> > on another type of pointer?
> 
> ptr is of type int *.  Assigning a struct some * to an int * object is
> an error.  C, however, does not really have errors -- it has situations
> that compiler must report.  These are called constraint violations and
> your assignment is an example of one.
> 
> Your suggestion does not achieve anything because it does not solve the
> problem.  You can't access the struct member after the assignment any
> more that you could before.
> 
well it may be, i dont remember such (in a way) silly details (details that can be seen as silly in some way)

if so

1) maybe such change to c would be ok, its just shorter compared to defining second variable
2) use

foo(void *ptr_)
{
 struct some* ptr = (struct some*) ptr_;

  ///....
  //.....
}

just ad underscore and that line, just to give proper type

if no just revrite, that code was not big its a task for 10 minutes?

[toc] | [prev] | [next] | [standalone]

#140104 — Re: compiling [old] c code

fir <profesor.fir@gmail.com> writes:

> W dniu wtorek, 22 stycznia 2019 23:45:50 UTC+1 użytkownik Ben Bacarisse napisał:
>> fir <profesor.fir@gmail.com> writes:
>> 
>> > W dniu wtorek, 22 stycznia 2019 17:46:35 UTC+1 użytkownik Ben Bacarisse napisał:
>> >> fir <profesor.fir@gmail.com> writes:
>> >> 
>> >> > W dniu poniedziałek, 21 stycznia 2019 19:34:08 UTC+1 użytkownik Ben Bacarisse napisał:
>> <snip>
>> >> >> Apart form the "big union" idea that's already been mentioned, you coud
>> >> >> try a macro:
>> >> >> 
>> >> >> #define PTR(p, s) ((struct s *)(p))
>> >> >> 
>> >> >> and re-write things like
>> >> >> 
>> >> >>   ttype = t->vtype;
>> >> >> 
>> >> >> as
>> >> >> 
>> >> >>   ttype = PTR(t, varblock)->vtype;
>> >> >> 
>> >> >> You might even be able to automate this a bit by using something like
>> >> >> Perl to record what structs have what members.
>> >> >
>> >> > it seems to me that he dont need to rewrite field acceses only
>> >> > maybe put
>> >> >
>> >> > ptr = (struct some*) ptr; //?
>> >> >
>> >> > in thet few places
>> >> 
>> >> This would be a constraint violation and yet would achieve nothing.
>> >> 
>> > what do you mean? you cant cast pointer
>> > on another type of pointer?
>> 
>> ptr is of type int *.  Assigning a struct some * to an int * object is
>> an error.  C, however, does not really have errors -- it has situations
>> that compiler must report.  These are called constraint violations and
>> your assignment is an example of one.
>> 
>> Your suggestion does not achieve anything because it does not solve the
>> problem.  You can't access the struct member after the assignment any
>> more that you could before.
>> 
> well it may be, i dont remember such (in a way) silly details (details
> that can be seen as silly in some way)

No, ptr = (struct some*) ptr; does nothing but make the program
undefined.

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#140109 — Re: compiling [old] c code

W dniu środa, 23 stycznia 2019 03:12:38 UTC+1 użytkownik Ben Bacarisse napisał:
> fir <profesor.fir@gmail.com> writes:
> 
> > W dniu wtorek, 22 stycznia 2019 23:45:50 UTC+1 użytkownik Ben Bacarisse napisał:
> >> fir <profesor.fir@gmail.com> writes:
> >> 
> >> > W dniu wtorek, 22 stycznia 2019 17:46:35 UTC+1 użytkownik Ben Bacarisse napisał:
> >> >> fir <profesor.fir@gmail.com> writes:
> >> >> 
> >> >> > W dniu poniedziałek, 21 stycznia 2019 19:34:08 UTC+1 użytkownik Ben Bacarisse napisał:
> >> <snip>
> >> >> >> Apart form the "big union" idea that's already been mentioned, you coud
> >> >> >> try a macro:
> >> >> >> 
> >> >> >> #define PTR(p, s) ((struct s *)(p))
> >> >> >> 
> >> >> >> and re-write things like
> >> >> >> 
> >> >> >>   ttype = t->vtype;
> >> >> >> 
> >> >> >> as
> >> >> >> 
> >> >> >>   ttype = PTR(t, varblock)->vtype;
> >> >> >> 
> >> >> >> You might even be able to automate this a bit by using something like
> >> >> >> Perl to record what structs have what members.
> >> >> >
> >> >> > it seems to me that he dont need to rewrite field acceses only
> >> >> > maybe put
> >> >> >
> >> >> > ptr = (struct some*) ptr; //?
> >> >> >
> >> >> > in thet few places
> >> >> 
> >> >> This would be a constraint violation and yet would achieve nothing.
> >> >> 
> >> > what do you mean? you cant cast pointer
> >> > on another type of pointer?
> >> 
> >> ptr is of type int *.  Assigning a struct some * to an int * object is
> >> an error.  C, however, does not really have errors -- it has situations
> >> that compiler must report.  These are called constraint violations and
> >> your assignment is an example of one.
> >> 
> >> Your suggestion does not achieve anything because it does not solve the
> >> problem.  You can't access the struct member after the assignment any
> >> more that you could before.
> >> 
> > well it may be, i dont remember such (in a way) silly details (details
> > that can be seen as silly in some way)
> 
> No, ptr = (struct some*) ptr; does nothing but make the program
> undefined.
> 
above i was sayin not on ptr = (struct some*) ptr, but ptr = (struct some*) ptr_

[toc] | [prev] | [next] | [standalone]

#140077 — Re: compiling [old] c code

W dniu poniedziałek, 21 stycznia 2019 13:21:02 UTC+1 użytkownik Ben Bacarisse napisał:
> fiziqs@gmail.com writes:
> 
> > On Monday, January 21, 2019 at 1:45:03 AM UTC+1, Geoff wrote:
> >> On Sun, 20 Jan 2019 14:51:00 -0800 (PST), fiziqs@gmail.com wrote:
> <snip>
> >> >I tried to compile a bit of code from the original Unix source and
> >> >ran into the following problem:
> <snip>
> > Actually, it was the EFL language, just to know if it is still
> > possible to compile this language:
> > https://minnie.tuhs.org/cgi-bin/utree.pl?file=4.4BSD/usr/src/old/efl
> 
> Is there a link that allows a directory to be downloaded?  It looks much
> more tractable than the very old C I, and others, were thinking about.
> The sources there are from about 1982 and look like normal K&R C.
> 


overally i could say i'm like dont like this style... as to code/architecture its probably ok but this naming sheme, non-capitals non-underscores: abbreviationglue is not the best probably

its like attempt (maybe even succesfull) to make c as a sorta assembly, when thiose abbreiationglued words would be new type of mnemonics

problem is assemblers are terribly nn readable, not saing that c in my style
(Sentences by capitals) is so much readable but if you take look over some set of those key-sentences (like 20 )
it chas a chance to say much more to you than set of 20 'mnemonics'

[toc] | [prev] | [next] | [standalone]

#140079 — Re: compiling [old] c code

W dniu wtorek, 22 stycznia 2019 12:34:24 UTC+1 użytkownik fir napisał:
> W dniu poniedziałek, 21 stycznia 2019 13:21:02 UTC+1 użytkownik Ben Bacarisse napisał:
> > fiziqs@gmail.com writes:
> > 
> > > On Monday, January 21, 2019 at 1:45:03 AM UTC+1, Geoff wrote:
> > >> On Sun, 20 Jan 2019 14:51:00 -0800 (PST), fiziqs@gmail.com wrote:
> > <snip>
> > >> >I tried to compile a bit of code from the original Unix source and
> > >> >ran into the following problem:
> > <snip>
> > > Actually, it was the EFL language, just to know if it is still
> > > possible to compile this language:
> > > https://minnie.tuhs.org/cgi-bin/utree.pl?file=4.4BSD/usr/src/old/efl
> > 
> > Is there a link that allows a directory to be downloaded?  It looks much
> > more tractable than the very old C I, and others, were thinking about.
> > The sources there are from about 1982 and look like normal K&R C.
> > 
> 
> 
> overally i could say i'm like dont like this style... as to code/architecture its probably ok but this naming sheme, non-capitals non-underscores: abbreviationglue is not the best probably
> 
> its like attempt (maybe even succesfull) to make c as a sorta assembly, when thiose abbreiationglued words would be new type of mnemonics
> 
> problem is assemblers are terribly nn readable, not saing that c in my style
> (Sentences by capitals) is so much readable but if you take look over some set of those key-sentences (like 20 )
> it chas a chance to say much more to you than set of 20 'mnemonics'

speaking about c code readibility maybe worth mention some extension idea i got once:

if a function has only one caller write this caller 9optionally though it might be maybe even enforced by some compiler flag) in that function header

instead 

int foo(int a) {}

int main.foo(int a) {}

and so on, (even chains could be probably allowed mian.foo.boo() )
 this way you can see immdiatelly which one function has one caller which not and  easier to read code back

[toc] | [prev] | [next] | [standalone]

#140073

fiziqs@gmail.com writes:
> On Monday, January 21, 2019 at 1:45:03 AM UTC+1, Geoff wrote:
>> On Sun, 20 Jan 2019 14:51:00 -0800 (PST), fiziqs@gmail.com wrote:
>> 
>> >Dear All,
>> >
>> >I tried to compile a bit of code from the original Unix source and
>> >ran into the following problem:
>> 
>> Can you post a link to this original Unix source so we can see what
>> vintage code you are talking about? Unix source is very ancient and
>> most C compilers probably can't compile it without special switches
>> to get them to conform to the dialect of C used at that time or else
>> extensive modification of those sources.
>
> Actually, it was the EFL language, just to know if it is still
> possible to compile this language:
> https://minnie.tuhs.org/cgi-bin/utree.pl?file=4.4BSD/usr/src/old/efl

According to the man page (efl.1), EFL is "Extended Fortran
Language".  The linked sources files appear to be the C
implementation of the efl command, a translator for EFL to Fortran.
EFL seems to be based on Ratfor, but with C-like data structures
in addition to Ratfor's control flow constructs.

A Ratfor preprocessor (translating Ratfor to Fortan 77) is still
available, for example via the "ratfor" package on Ubuntu.

> And sorry, I made a typo in the topic title, I meant "old C code", not "all".

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c

csiph-web