Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > alt.os.development > #8344 > unrolled thread
| Started by | "Alexei A. Frounze" <alexfrunews@gmail.com> |
|---|---|
| First post | 2015-07-11 20:39 -0700 |
| Last post | 2015-09-16 10:17 -0700 |
| Articles | 8 on this page of 88 — 7 participants |
Back to article view | Back to alt.os.development
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-07-11 20:39 -0700
Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-12 04:24 -0400
Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-07-12 03:17 -0700
Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-13 03:28 -0400
Re: Smaller C "James Harris" <james.harris.1@gmail.com> - 2015-07-12 19:12 +0100
Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-07-12 17:09 -0700
Re: Smaller C "James Harris" <james.harris.1@gmail.com> - 2015-07-13 11:10 +0100
Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-13 23:13 -0400
Re: Smaller C "James Harris" <james.harris.1@gmail.com> - 2015-07-14 09:08 +0100
Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-15 02:23 -0400
Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-08-15 02:12 -0700
Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-09-06 15:54 -0700
Re: Smaller C "Benjamin David Lunt" <zfysz@fysnet.net> - 2015-09-07 12:19 -0700
Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-09-07 13:30 -0700
Re: Smaller C "Benjamin David Lunt" <zfysz@fysnet.net> - 2015-09-09 19:38 -0700
Re: Smaller C "Benjamin David Lunt" <zfysz@fysnet.net> - 2015-09-09 19:49 -0700
Re: Smaller C "Benjamin David Lunt" <zfysz@fysnet.net> - 2015-09-09 20:58 -0700
Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-09-10 01:45 -0700
Re: Smaller C "Benjamin David Lunt" <zfysz@fysnet.net> - 2015-09-10 10:45 -0700
Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-09-10 23:20 -0700
Re: Smaller C "wolfgang kern" <nowhere@never.at> - 2015-09-11 09:26 +0200
Re: Smaller C "wolfgang kern" <nowhere@never.at> - 2015-09-11 09:50 +0200
Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-09-11 00:58 -0700
Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-09-11 17:38 -0400
Re: Smaller C "James Harris" <james.harris.1@gmail.com> - 2015-09-11 23:39 +0100
Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-09-11 19:39 -0400
Re: Smaller C "James Harris" <james.harris.1@gmail.com> - 2015-09-12 11:22 +0100
Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-09-12 02:21 -0700
Re: Smaller C "wolfgang kern" <nowhere@never.at> - 2015-09-12 21:53 +0200
Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-09-13 03:37 -0400
Re: Smaller C "James Harris" <james.harris.1@gmail.com> - 2015-09-13 09:49 +0100
Re: Smaller C "wolfgang kern" <nowhere@never.at> - 2015-09-13 12:58 +0200
Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-09-13 07:32 -0400
Re: Smaller C "James Harris" <james.harris.1@gmail.com> - 2015-09-13 19:05 +0100
Re: Smaller C "James Harris" <james.harris.1@gmail.com> - 2015-09-14 13:19 +0100
Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-09-15 00:01 -0400
Re: Smaller C "James Harris" <james.harris.1@gmail.com> - 2015-09-18 14:48 +0100
Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-09-26 16:23 -0400
Re: Smaller C James Harris <james.harris.1@gmail.com> - 2015-09-27 00:23 +0100
Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-09-26 16:37 -0700
Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-09-27 10:17 -0400
Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-09-27 10:24 -0400
Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-09-27 10:46 -0400
Re: Smaller C James Harris <james.harris.1@gmail.com> - 2016-01-16 16:14 +0000
Re: Smaller C Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-01-23 13:20 -0500
Re: Smaller C James Harris <james.harris.1@gmail.com> - 2016-01-27 13:52 +0000
Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-09-27 10:28 -0400
Re: Smaller C James Harris <james.harris.1@gmail.com> - 2016-01-16 16:31 +0000
Re: Smaller C Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-01-23 13:20 -0500
Re: Smaller C "James Harris" <james.harris.1@gmail.com> - 2015-09-18 16:21 +0100
Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-09-20 17:25 -0700
Re: Smaller C "wolfgang kern" <nowhere@never.at> - 2015-09-13 12:43 +0200
Re: Smaller C "James Harris" <james.harris.1@gmail.com> - 2015-09-13 09:21 +0100
Re: Smaller C "wolfgang kern" <nowhere@never.at> - 2015-09-13 13:02 +0200
Re: Smaller C "James Harris" <james.harris.1@gmail.com> - 2015-09-13 19:09 +0100
Re: Smaller C "Benjamin David Lunt" <zfysz@fysnet.net> - 2015-09-11 13:32 -0700
Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-09-11 18:51 -0400
Re: Smaller C "Benjamin David Lunt" <zfysz@fysnet.net> - 2015-09-11 18:16 -0700
Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-09-12 02:36 -0700
Re: Smaller C "James Harris" <james.harris.1@gmail.com> - 2015-09-12 11:56 +0100
Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-09-13 03:45 -0400
Re: Smaller C "James Harris" <james.harris.1@gmail.com> - 2015-09-13 10:28 +0100
Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-09-13 02:53 -0700
Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-09-13 11:17 -0400
Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-09-13 16:54 -0700
Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-09-13 21:39 -0400
Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-09-13 20:31 -0700
Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-09-13 09:03 -0400
Re: Smaller C "James Harris" <james.harris.1@gmail.com> - 2015-09-13 19:48 +0100
Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-09-13 21:33 -0400
Re: Smaller C "James Harris" <james.harris.1@gmail.com> - 2015-09-14 23:17 +0100
Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-09-20 17:37 -0400
Re: Smaller C "James Harris" <james.harris.1@gmail.com> - 2015-09-20 23:46 +0100
Re: Smaller C "Benjamin David Lunt" <zfysz@fysnet.net> - 2015-09-11 21:37 -0700
Re: Smaller C "Benjamin David Lunt" <zfysz@fysnet.net> - 2015-09-11 22:29 -0700
Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-09-12 03:25 -0700
Re: Smaller C "Benjamin David Lunt" <zfysz@fysnet.net> - 2015-09-12 11:18 -0700
Re: Smaller C "Benjamin David Lunt" <zfysz@fysnet.net> - 2015-09-12 11:39 -0700
Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-09-13 03:47 -0400
Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-09-13 11:31 -0400
Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-09-13 02:00 -0700
Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-09-13 11:31 -0400
Re: Smaller C "Benjamin David Lunt" <zfysz@fysnet.net> - 2015-09-13 09:15 -0700
Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-09-12 02:45 -0700
Re: Smaller C "Benjamin David Lunt" <zfysz@fysnet.net> - 2015-09-12 10:55 -0700
Re: Smaller C "Benjamin David Lunt" <zfysz@fysnet.net> - 2015-09-15 19:23 -0700
Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-09-16 03:03 -0700
Re: Smaller C "Benjamin David Lunt" <zfysz@fysnet.net> - 2015-09-16 10:17 -0700
Page 5 of 5 — ← Prev page 1 2 3 4 [5]
| From | "Alexei A. Frounze" <alexfrunews@gmail.com> |
|---|---|
| Date | 2015-09-13 02:00 -0700 |
| Message-ID | <f6eeb7f2-d968-4ce9-9093-8f1019efeb6d@googlegroups.com> |
| In reply to | #8762 |
On Saturday, September 12, 2015 at 11:18:53 AM UTC-7, Benjamin David Lunt wrote:
> "Alexei A. Frounze" <...@gmail.com> wrote in message
> news:d372f8e1-159d-4c24-8d70-f08b14891c98@googlegroups.com...
> > On Friday, September 11, 2015 at 10:29:36 PM UTC-7, Benjamin David Lunt
> > wrote:
> >> Alex,
> >>
> >> Just another comment, I hope you don't mind.
>
> <snip code>
>
> >> Anyway, just a thought. Hope you don't mind me asking
> >> these questions. It is more for my sake, "talking" it out
> >> kind of helps visualize it for me.
> >
> > This is one of those features that require keeping potentially
> > a lot of data in the memory of the compiler, which isn't
> > something I'm happy about. Nor am I happy about restructuring
> > the code in order to be able to go back in the input or the
> > output. I've made two small exceptions for very common and
> > limited cases: switch cases (the constants and the labels are
> > accumulated internally in the compiler, but usually there are
> > not too many of them) and function prolog(ue)s (the structure/
> > layout of this code is known beforehand and its size is small,
> > so, over/re-writing it in the output file is easy and cheap).
> > Arrays, OTOH, can be pretty big. And this feature is especially
> > useful with big arrays. IOW, it asks for a full implementation,
> > needing either a lot of memory potentially or complicating the
> > code. I've repeatedly stated that I'm not making yet another
> > full and good compiler, I'm making a relatively small and
> > simple one, non-optimizing and without some languages or
> > usability features.
>
> I completely understand. I was going through some C compiler
> sights looking for example source to test a given compiler and
> found the article I mentioned before.
>
> Of course my compiler spit up on the declaration line and so I
> looked through it a bit to see what it would take to implement
> this feature.
>
> If it is only implemented on non-structure/union declares, then
> it shouldn't be to difficult to implement.
>
> As for the structure declares, such as
>
> struct SOMESTRUCT {
> int foo;
> int bar;
> } = s[100] {
> [40].foo = 1,
> [50].bar = 2
> };
>
> this may take a little more work, though maybe not too much,
> since .foo and .bar are simply offsets from the [40] element
> anyway.
>
> Just thought I would comment.
You should pay extra attention to the details of this feature.
Designated initializers are permitted to initialize array/struct
elements in any order. So, they may first initialize element 1000
and then element 5, or they can initialize the same element
more then once, either explicitly or implicitly. So, what do you
do? Do you generate a bunch of "dd 1234"'s only to have to later
go back and overwrite them? Or do you try to avoid the fun with
I/O and do this in memory instead? Potentially gobbling megabytes
of memory? Any reasonable alternatives?
> > ...you will have to implement it yourself.
>
> The only concern I have, and it only concerns myself on this, is
> if I implement it in my code, if I ever need to compare your
> additions, it is a lot more work to work around my implementation
> compared to your implementation/additions/enhancements.
>
> If I start to implement things of this sort, I then have
> to pull away from keeping my code somewhat relative to yours.
> I don't know if I am ready to do that yet :-)
>
> Thanks,
> Ben
>
> P.S. What I was looking for were snippets of code that implement
> techniques that most people don't use.
>
> For example, the following technique is seldom used but makes
> for an excellent syntax check on the coder's point of view.
>
> if (2 == i)
>
> which, by the way, your compiler compiles just fine.
>
> The above technique, for those who have not seen it, makes
> sure that the coder doesn't accidentally forget the second
> '=' sign as in
>
> if (i = 2) // <-- coder should have done 'if (i == 2)'
>
> The above will produce a TRUE response every time no matter
> what 'i' contains. The compiler won't catch it as a syntax
> mistake since it is valid syntax. It would be up to the
> coder to catch it. However, if the immediate is first,
> the compiler will catch it every time.
>
> By the way Alex, SmallerC gives an error for
>
> if (2 = i)
>
> where as my compiler crashes. I must have a null-pointer
> or something. I will have to look into that.
>
> See, this is why I was looking for code like this :-)
>
> Anyway, thanks. Ben
You need to write or steal tests. Or you could generate them.
The gcc test package has thousands of tests. You can download
them and play with them. Fun guaranteed. :)
Alex
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <boo@fasdfrewar.cdm> |
|---|---|
| Date | 2015-09-13 11:31 -0400 |
| Message-ID | <op.x4wqq6glyfako5@localhost> |
| In reply to | #8771 |
On Sun, 13 Sep 2015 05:00:07 -0400, Alexei A. Frounze <alexfrunews@gmail.com> wrote: > On Saturday, September 12, 2015 at 11:18:53 AM UTC-7, Benjamin David Lunt wrote: >> Anyway, thanks. Ben > > You need to write or steal tests. Or you could generate them. > The gcc test package has thousands of tests. You can download > them and play with them. Fun guaranteed. :) I posted a long list of test suites etc some years ago: https://groups.google.com/d/msg/comp.lang.misc/avRejkndwDc/WUsKT57oRFIJ Usenet msg-id <f6412q$lbf$1@aioe.org> If a link is bad, you need it, and you can't find it, mention it. I'll attempt to relocate it. Rod Pemberton -- Just how many texting and calendar apps does humanity need?
[toc] | [prev] | [next] | [standalone]
| From | "Benjamin David Lunt" <zfysz@fysnet.net> |
|---|---|
| Date | 2015-09-13 09:15 -0700 |
| Message-ID | <mt47gv$jv3$1@speranza.aioe.org> |
| In reply to | #8771 |
"Alexei A. Frounze" <alexfrunews@gmail.com> wrote in message news:f6eeb7f2-d968-4ce9-9093-8f1019efeb6d@googlegroups.com... > On Saturday, September 12, 2015 at 11:18:53 AM UTC-7, Benjamin David Lunt > wrote: >> this may take a little more work, though maybe not too much, >> since .foo and .bar are simply offsets from the [40] element >> anyway. >> >> Just thought I would comment. > > You should pay extra attention to the details of this feature. > Designated initializers are permitted to initialize array/struct > elements in any order. So, they may first initialize element 1000 > and then element 5, or they can initialize the same element > more then once, either explicitly or implicitly. So, what do you > do? Do you generate a bunch of "dd 1234"'s only to have to later > go back and overwrite them? Or do you try to avoid the fun with > I/O and do this in memory instead? Potentially gobbling megabytes > of memory? Any reasonable alternatives? I was thinking about this also, it would either have to be all in memory, or not at all. If I do implement this (not very likely at the moment), I would require everything to be consecutive. Every instance would have to be an index higher than the last one. >> By the way Alex, SmallerC gives an error for >> >> if (2 = i) >> >> where as my compiler crashes. I must have a null-pointer >> or something. I will have to look into that. >> >> See, this is why I was looking for code like this :-) >> >> Anyway, thanks. Ben > > You need to write or steal tests. Or you could generate them. > The gcc test package has thousands of tests. You can download > them and play with them. Fun guaranteed. :) I was thinking of writing my own, but I know that I don't know all of the things to check for. It looks like Rod has given a good list, and I will go that route. Thanks Rod. Thanks, Ben
[toc] | [prev] | [next] | [standalone]
| From | "Alexei A. Frounze" <alexfrunews@gmail.com> |
|---|---|
| Date | 2015-09-12 02:45 -0700 |
| Message-ID | <09a0572c-ea77-41eb-b089-d0807d6f0367@googlegroups.com> |
| In reply to | #8750 |
On Friday, September 11, 2015 at 9:37:57 PM UTC-7, Benjamin David Lunt wrote:
> "Alexei A. Frounze" <...@gmail.com> wrote in message
> news:39da71f8-7e21-4fcb-84da-263d5c81059f@googlegroups.com...
> > One more improvement for Ben's 50+K executable. :)
> > Actually, I've had a couple of requests for this.
> >
> > Anyway, the prologue/epilogue parts are now shorter.
> >
> > This is what Smaller C used to generate:
> > _foo:
> > push bp
> > mov bp, sp
> > jmp L1
> > L2:
> > ...
> > leave
> > ret
> > L1:
> > sub sp, size_of_locals
> > jmp L2
> >
> > This is what it generates now:
> > _foo:
> > push bp
> > mov bp, sp
> > sub sp, size_of_locals
> > ...
> > leave
> > ret
> >
> > If there are no locals, there's no sub either. This shaves ~500 bytes
> > off a 64KB 16-bit code section.
> >
> > The trick? fgetpos()/fsetpos() majic.
> > The price? Must always supply the output assembly file name to smlrc.
>
> Alex,
>
> I hope you don't mind, may I make a small suggestion for your above
> code?
>
> @@ -6965,7 +6965,7 @@
> #endif
> #endif
> GenFxnProlog();
> - CurFxnEpilogLabel = LabelCnt++;
> + CurFxnEpilogLabel = 0;
>
> AddFxnParamSymbols(lastSyntaxPtr);
>
> @@ -6997,7 +6997,9 @@
> GenExpr();
> }
>
> - GenNumLabel(CurFxnEpilogLabel);
> + // only need to include the label if we used it
> + if (CurFxnEpilogLabel > 0)
> + GenNumLabel(CurFxnEpilogLabel);
>
> #ifndef MIPS
> #ifdef CAN_COMPILE_32BIT
> @@ -7460,7 +7462,7 @@
> // If this return is the last statement in the function, the epilogue
> immediately
> // follows and there's no need to jump to it.
> if (!(tok == '}' && ParseLevel == 1 && !Main))
> - GenJumpUncond(CurFxnEpilogLabel);
> + GenJumpUncond(CurFxnEpilogLabel = LabelCnt++);
> }
> else if (tok == tokWhile)
> {
>
> Currently, whether the label is needed or not, your/my code supplies
> the ending label 'CurFxnEpilogLabel'. No big deal, the output assembles
> just fine. However, one less label to see/process/store/etc., if
> you make the above change.
>
> Hope you don't mind me sending you a diff and a suggestion.
>
> Please let me know if the above change will break anything though.
I think it should just work. Though, compared with all other
jumps and labels, which are kind of needed, this probably saves you
just some 50-100 in your loader.sys. I'll take a look to see if
there are more unnecessary branches that can be eliminated easily.
But while I have little against this, it's a very little help to
the assembler. And it looks like it's good enough for me the way
it is now.
I'm more concerned about those unnecessary instructions. :)
I've, if you've noticed it, started passing tokReturn to the code
generator. Even though it's not used on x86 at the moment, it
signals that the value from the expression is used. So, when
there's no tokIf/tokIfNot/tokReturn at the end of stack[], the
code generator may remove some unnecessary sign/zero extensions
and other things and generate code only for expression side
effects (reads/writes/calls).
Alex
[toc] | [prev] | [next] | [standalone]
| From | "Benjamin David Lunt" <zfysz@fysnet.net> |
|---|---|
| Date | 2015-09-12 10:55 -0700 |
| Message-ID | <mt1qa8$gsp$1@speranza.aioe.org> |
| In reply to | #8754 |
"Alexei A. Frounze" <alexfrunews@gmail.com> wrote in message news:09a0572c-ea77-41eb-b089-d0807d6f0367@googlegroups.com... > On Friday, September 11, 2015 at 9:37:57 PM UTC-7, Benjamin David Lunt > wrote: >> >> I hope you don't mind, may I make a small suggestion for your above >> code? <snip patch> >> Currently, whether the label is needed or not, your/my code supplies >> the ending label 'CurFxnEpilogLabel'. No big deal, the output assembles >> just fine. However, one less label to see/process/store/etc., if >> you make the above change. >> >> Hope you don't mind me sending you a diff and a suggestion. >> >> Please let me know if the above change will break anything though. > > I think it should just work. Though, compared with all other > jumps and labels, which are kind of needed, this probably saves you > just some 50-100 in your loader.sys. I'll take a look to see if > there are more unnecessary branches that can be eliminated easily. > But while I have little against this, it's a very little help to > the assembler. And it looks like it's good enough for me the way > it is now. > > I'm more concerned about those unnecessary instructions. :) > I've, if you've noticed it, started passing tokReturn to the code > generator. Even though it's not used on x86 at the moment, it > signals that the value from the expression is used. So, when > there's no tokIf/tokIfNot/tokReturn at the end of stack[], the > code generator may remove some unnecessary sign/zero extensions > and other things and generate code only for expression side > effects (reads/writes/calls). I understand, I was just going through some of the code and found that there was usually an unused label emitted and wanted to know why. As for the compiler and assembler, it makes little to no difference. However, as to the human eye, studying the produced code, it makes a bit of difference when trying to find out where jumps are headed. No worries, just thought I would comment. Thanks, Ben
[toc] | [prev] | [next] | [standalone]
| From | "Benjamin David Lunt" <zfysz@fysnet.net> |
|---|---|
| Date | 2015-09-15 19:23 -0700 |
| Message-ID | <mtajr5$q4f$1@speranza.aioe.org> |
| In reply to | #8344 |
Alex,
Just a comment, no reply is expected, though it seems that we
have quite the discussion going about things like this now.
I haven't had a chance to read them all, but what happened :-)
Anyway, in the following function declaration:
void X0() {
return;
}
The parameter list is assumed or not given. This is to be
K&R compatible, correct? This actually allows any number of
parameters to be passed to it, though the output is undefined
if the function is passed an unknown count of parameters.
i.e.: isn't
void X0() {
the same as
void X0(...) {
Anyway, to my comment. If you plan on supporting that form,
do you plan on supporting the assumed 'int' type as in:
X2() {
return;
}
or
X3(void) {
return;
}
i.e., currently, SmallerC doesn't like the X2 (or X3) since
it is expecting a declaration.
I believe that the
void X0() {
and
X0() {
are both pre-C89/90 (K&R) syntax, but C99, etc. allow it.
SmallerC allows the first, void X0(), but not the second, XO().
Again, no reply expected, just thought you might be interested.
Also, others may have input too, since there is a discussion
on 'versions' of the specification within other threads.
Ben
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Forever Young Software
http://www.fysnet.net/index.htm
http://www.fysnet.net/osdesign_book_series.htm
To reply by email, please remove the zzzzzz's
Batteries not included, some Assembly required.
[toc] | [prev] | [next] | [standalone]
| From | "Alexei A. Frounze" <alexfrunews@gmail.com> |
|---|---|
| Date | 2015-09-16 03:03 -0700 |
| Message-ID | <02f6d568-49d2-49c8-864a-d428b3678e6c@googlegroups.com> |
| In reply to | #8811 |
On Tuesday, September 15, 2015 at 7:23:36 PM UTC-7, Benjamin David Lunt wrote:
> Alex,
>
> Just a comment, no reply is expected, though it seems that we
> have quite the discussion going about things like this now.
> I haven't had a chance to read them all, but what happened :-)
>
> Anyway, in the following function declaration:
>
> void X0() {
> return;
> }
>
> The parameter list is assumed or not given. This is to be
> K&R compatible, correct?
It's ANSI C, not sure about anything prior. Obsoleted with
C99. Means no (=zero) parameters, just like void X0(void).
> This actually allows any number of
> parameters to be passed to it, though the output is undefined
> if the function is passed an unknown count of parameters.
Not quite. C99 says:
An empty list in a function declarator that is part of a
definition of that function [case in point] specifies that
the function has no parameters. The empty list in a function
declarator that is not part of a definition of that function
specifies that no information about the number or types of
the parameters is supplied.
IOW, if all you have is
void X0(); // can bear extern
then you can pass anything, provided there's no UB (i.e.
parameters match in type and number and things like that
= your responsibility).
Strangely, if you provide a definition like this:
void X0() {}
gcc lets you call it with arguments in C99 mode (-std=c99
-Wall -Wextra -pedantic -O2) without warnings or errors.
It doesn't look right per C99. Smaller C lets you do the
same.
5th ed. of oft-referred H&S says:
A function call is governed by a prototype when:
1. a declaration for the function (or type) is visible and
the declaratioin is in prototype form, or
2. the function definition is visible and that definition
is in prototype form
That may explain the above oddity. Though I haven't found
yet where C99 would state or imply the exact same logic.
> i.e.: isn't
>
> void X0() {
>
> the same as
>
> void X0(...) {
Nope. The latter needs at least one formal parameter before
the ellipsis. It won't even compile.
> Anyway, to my comment. If you plan on supporting that form,
What form? You can use empty () today.
> do you plan on supporting the assumed 'int' type as in:
>
> X2() {
> return;
> }
>
> or
>
> X3(void) {
> return;
> }
>
> i.e., currently, SmallerC doesn't like the X2 (or X3) since
> it is expecting a declaration.
>
> I believe that the
>
> void X0() {
> and
> X0() {
>
> are both pre-C89/90 (K&R) syntax, but C99, etc. allow it.
>
> SmallerC allows the first, void X0(), but not the second, XO().
>
> Again, no reply expected, just thought you might be interested.
> Also, others may have input too, since there is a discussion
> on 'versions' of the specification within other threads.
Utterly disinterested. The feature has been obsoleted for 15+
years (=since C99), it further promotes bugs and it costs in
terms of coding. All that just to let someone lazy keep being
lazy and keep writing sloppy code. Spell your ints and voids
and move on already.
Again, if you want it, you can implement it. But I bet you
don't want it enough to implement.
:)
Alex
[toc] | [prev] | [next] | [standalone]
| From | "Benjamin David Lunt" <zfysz@fysnet.net> |
|---|---|
| Date | 2015-09-16 10:17 -0700 |
| Message-ID | <mtc87i$fuo$1@speranza.aioe.org> |
| In reply to | #8812 |
"Alexei A. Frounze" <alexfrunews@gmail.com> wrote in message news:02f6d568-49d2-49c8-864a-d428b3678e6c@googlegroups.com... > On Tuesday, September 15, 2015 at 7:23:36 PM UTC-7, Benjamin David Lunt > wrote: <snip 'void func()' stuff> > Again, if you want it, you can implement it. But I bet you > don't want it enough to implement. > > :) > > Alex You guessed right. :) I was just curious of your thoughts on the subject. Thanks, Ben
[toc] | [prev] | [standalone]
Page 5 of 5 — ← Prev page 1 2 3 4 [5]
Back to top | Article view | alt.os.development
csiph-web