[bug #58435] make 4.3 is not c89 compliant

[anonymous]

URL:
  

 Summary: make 4.3 is not c89 compliant
 Project: make
Submitted by: None
Submitted on: Sat 23 May 2020 10:35:54 PM UTC
Severity: 3 - Normal
  Item Group: Build/Install
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: None
Operating System: POSIX-Based
   Fixed Release: None
   Triage Status: None

___

Details:

make 4.2.1 builds with compilers that default to strict c89, but make 4.3 does
not due to use of variable argument macros (a c99 feature) in lib/verify.h.

specifically, i am using the sgi mipspro 7.4.3 compiler on irix 6.5.22.

please consider either returning to c89 compliance when compiled without
support for later standards, or officially requiring C99 and using an
autotools macro such as AC_PROG_CC_C99 to ensure that necessary flags for c99
compilation are passed to the compiler.




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

Re: math expressions (was: Re: Tail call elimination)

[Pete Dietl]

> I understand what Tim is saying but I still prefer to have a single
> function.  I want to reduce the "namespace leakage" for these
> capabilities.  If we decide to add more operations to this in the
> future I don't want it colliding with something else we want to do.
>
> However, sometimes it's hard to see exactly how something will look
> until we actually see it.

Hm so does that imply that we're still on the fence?
What can we do to resolve this? Take a poll?
You're the benevolent dictator right Paul? :)

> > I propose the following (a variation of example 2):
> >
> > $(math + 5 (/ (* (/ (* 2 9) (+ 7 5 4)) (* 1024 1024)) 19))
>
> If we want to support grouping directly we're still requiring the
> function to be recursive.  If we use make expansion to provide grouping
> the function doesn't need to be recursive (of course, we get recursion
> implicitly because of make's expansion).

By recursive do you mean the implementation of
$(math) in the make source is recursive?
I only prefer my suggestion because it removes a lot
of dollar signs and `insert name of function here` repetition.

It you need more convincing, one could argue that parsing it directly
would likely lead to a more efficient implementation -- we would
have the opportunity to implement this as an iterative process; either
by loops or tail-call recursion. But I'll reiterate that my motivation is
a more concise syntax.

math expressions (was: Re: Tail call elimination)

[Paul Smith]

On Fri, 2020-05-22 at 23:14 -0500, Pete Dietl wrote:
> So we are back to debating between many functions or (one or two)
> functions. Anyone else care to weigh in?

I understand what Tim is saying but I still prefer to have a single
function.  I want to reduce the "namespace leakage" for these
capabilities.  If we decide to add more operations to this in the
future I don't want it colliding with something else we want to do.

However, sometimes it's hard to see exactly how something will look
until we actually see it.

> As for a name for $(cond), we could call it 
> $(alu ...)
> And put arithmetic and logical operations in it :)

I guess this was not serious but... no :).

> I propose the following (a variation of example 2):
> 
> $(math + 5 (/ (* (/ (* 2 9) (+ 7 5 4)) (* 1024 1024)) 19))
> 
> This would involve doing our own parsing of the argument,
> however this should be trivial since we are using prefix notation.

If we want to support grouping directly we're still requiring the
function to be recursive.  If we use make expansion to provide grouping
the function doesn't need to be recursive (of course, we get recursion
implicitly because of make's expansion).

> I don’t like using $(cond)
> Because because I sort of want to option to implement cond like in
> Scheme.

I suspected someone would mention this :).  I want to reiterate that
even though we're adding some functionality, I'm not interested in
creating an entire programming language in make.

Today we have $(if ...) which has then/else clauses.  I understand that
a Lisp cond wouldn't need to nest each condition but I'm not convinced
that's a serious issue in any real makefiles.

And if you really want Lisp you can use the Guile integration.

So, I'm not too worried about this.  But, feel free to come up with
other names: I'm not saying it has to be that one.