Re: error reporting

[Edward Welbourne]

 Note that in Unix, vsnprintf() returns the TOTAL number of chars
 needed (add 1 for the null).

This is not correct.  The buffer size (that you pass in) is the total
number of bytes available (and the most the function shall use,
including the terminator); but the *return* is the strlen() that would
have resulted had the buffer been big enough.  If this is the buffer
size you passed in, the output has been truncated, in order to fit in
the terminator, by one byte; but the return doesn't include the
terminator.

 If the output would overflow the buffer, then you would get a return
 value larger than the specified buffer size.

Yes, and you need to add one to the return value to get the buffer size
you need for the subsequent call that'll get the job done properly.  The
function hasn't added one for the terminator: you need to do that.

 In Windoze, vsnprintf() will return -1 if the buffer would be
 overflowed,

This is quite usual amongst iron-age implementations of libc.

Eddy.

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: error reporting

[Edward Welbourne]

 I'm really not excited about the prospect of continuing to add new
 project files every year for each new version of Visual Studio.  Isn't
 there any sort of backward-compatibility that allows the older files to
 work in newer Visual Studio releases?

Don't hold your breath - it might be there, but think about the upgrade
treadmill for a moment and you'll see why it's not in MS's interests to
support anything other than sure, we can read the old project file and
upgrade it to the incompatible new version.  That way, the developer
who has splurged on the new version shares unusable project files with
the rest of the team, who are pressured thereby into upgrading.  Same as
the reason word processor file formats have to change at every release -
use network effects to turn your customers into stooges for your
marketing department.

Eddy.

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: vms:test variables

[John E. Malmberg]

On 4/8/2014 12:48 PM, h.becker wrote:

On 04/08/2014 07:28 AM, John E. Malmberg wrote:

On 4/7/2014 4:37 PM, h.becker wrote:

$ @TEST_MAKE

features.dir/archives ...

  ^^



This is a day one bug in the older Perl on VMS versions that was fixed
in about the Perl 5.10 timeframe, but the fix was not made the default
behavior until Perl 5.18, as it is tied to supporting EFS character
filenames.


test_make did not complain about the perl version so I concluded perl
is/was OK. It seems it isn't:
$ perl -V
Summary of my perl5 (revision 5 version 10 subversion 0) configuration:
...


The test is mainly testing for the older Perl 5.8.x from the HP kit to 
avoid using it.  Craig Berry did a manual custom install of 5.10 on 
Encompasserve that looks a lot like the new PCSI kit install for 5.18, 
so the test_make.com procedure did not detect that it was an older Perl.


I will find out if Craig Berry has time to update Perl on Encompasserve, 
or if he is ok if I just do it.



Perl 5.18 and later suppresses the incorrect .dir being appended to
paths by default.  The incorrect behavior can be optionally turned on
for existing PERL/VMS scripts that expect the buggy behavior.  I did not
test the script with older versions of Perl, or with the older behavior
enabled.


and can the incorrect behavior turned off in older versions? (OK,
temporarily I can change run_make_tests.pl).


$DEFINE DECC$EFS_CHARSET ENABLE

Should do the trick.  That turns off most of the backwards behavior.
As long as there are not any ODS-5 specific files in the directory, the 
older behavior mostly works.


Some other DECC$ logicals may also be needed for fixing various bugs in 
the UNIX format file name parsing, as the CRTL is by default maintaining 
backwards compatibility for programs that are expecting buggy behavior.


Most of the fixes should be in Perl 5.10, just not enabled by default.


OK, I can run one when I specify one, but it fails due to bash's ::


It is not failing, the warning from DCL is written out, but does not
otherwise affect the execution.  Rather than modify all the tests that
were using : as null command, I changed the compare_output routine in
the test harness to ignore it.


Make, at least the version I made, propagates the DCL warning and stops
with an error:

$ mcr USR_ODS5:[BECKER_H.MAKE.MAKE]MAKE -f work/variables/undefine.mk_2
undefined
%DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
work/variables/undefine.mk_2:11: recipe for target 'all' failed
make: *** [all] Error 0x380b0
%DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
$ ed ^UP^work/variables/undefine.mk_2
 1
*s/@:/@continue/W
11   all: ;@continue
1 substitution
*exit
USR_ODS5:[BECKER_H.make.x.tests]UNDEFINE.MK_2;1 11 lines

$ rena UNDEFINE.MK_2;1 ^UP^work/variables/undefine.mk_2
$ mcr USR_ODS5:[BECKER_H.MAKE.MAKE]MAKE -f work/variables/undefine.mk_2
undefined
$



GNU make doesn't care about the commands, but either my make (likely, or
maybe) behaves, or the used commands (I don't see any in this test case)
behave, or the test environment behaves differently:

$ mcr USR_ODS5:[BECKER_H.MAKE.MAKE]MAKE -f work/variables/undefine.mk
recursive simple recursive
undefined undefined undefined
%DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
work/variables/undefine.mk:19: recipe for target 'all' failed
make: *** [all] Error 0x380b0
%DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
$

and with the replacement for ::
$ mcr USR_ODS5:[BECKER_H.MAKE.MAKE]MAKE -f work/variables/undefine.mk
recursive simple recursive
undefined undefined undefined
$

but in the log/diff created under control of the perl script there is

$ ty ^UP^work/variables/undefine.log
recursive simple recursive

undefined undefined recursive

$ ty ^UP^work/variables/undefine.diff
*** work/variables/undefine.baseTue Apr  8 13:22:21 2014
--- work/variables/undefine.log Tue Apr  8 13:22:21 2014
***
*** 1,2 
   recursive simple recursive
! undefined undefined undefined
--- 1,4 
   recursive simple recursive
!
! undefined undefined recursive
!
$

which matches your output. This is at least confusing, one would expect
to see the same output in a stand-alone run and in a run under the
control of the perl script.


That is something that needs to be investigated.  Something about 
running in the test script is changing the behavior of GNU make for a 
few tests.


I saw only about 2 cases where a test passed when I manually ran the 
makefile and it failed on the test harness.


I am sure that the test harness and tests will need further changes as 
we progress, and that we will need to add tests to explicitly test for 
intentional VMS differences in behavior.


Regards,
-John



___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make