Friday, August 21, 2020

Digest for comp.lang.c++@googlegroups.com - 25 updates in 3 topics

RM <robert_magdziarz@wp.pl>: Aug 21 08:06AM +0200

W dniu 20.08.2020 o 21:09, Bo Persson pisze:
 
> So which line is number 79?
 
>     Bo Persson
 
Line 79:
obfuscator() {
Bo Persson <bo@bo-persson.se>: Aug 21 09:15AM +0200

On 2020-08-21 at 08:06, RM wrote:
 
>>      Bo Persson
 
> Line 79:
>     obfuscator() {
 
Ok, so the problem manifests itself in the constructor. The next hint
from the runtime is that it happens in a call to operator+. The only
place I can see is this line:
 
keywords = string(" ") + reserved_keywords + string(" ") +
strtoupper(reserved_keywords) + string(" ");
 
I wouldn't expect the well tested standard library parts to have a bug
that creates a std::string containing a null pointer, so the suspect is
likely to be the non-standard strtoupper.
 
 
Bo Persson
David Brown <david.brown@hesbynett.no>: Aug 21 09:48AM +0200


>> Don't use #define!
 
> Oh god, not this again. It should go in the moronic advice box along with
> "Never use gotos!".
 
Ian was a bit short here. The common advice is "don't use #define when
there are better ways to get the effect you want". (The same applies to
"goto", obviously.) And there are better ways to do it in this case, as
there usually are in C++.
 
> I'm guessing you've never written cross platform code or used the -D
> option with gcc/clang in makefiles.
 
Knowing a little of Ian's work, you are guessing incorrectly.
Pre-processor conditional compilation is a good reason for using
#define'd constants rather than "const", "constexpr" or "enum". So is C
compatibility, if that's important (it sometimes is in headers).
 
As an aside, it would be /so/ nice in C++ to have a way to access the
first and last (numerically) elements in an enumeration. Other
languages have it, like Ada's 'First and 'Last attributes, and Pascal's
"low" and "high" functions.
RM <robert_magdziarz@wp.pl>: Aug 21 10:05AM +0200

In debugger I saw random values of private const members (in
constructor). I changed const to constexpr.
Now I see different errors at sequent runs:
 
Program terminated with signal SIGABRT, Aborted.
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
51 ../sysdeps/unix/sysv/linux/raise.c: Nie ma takiego pliku ani katalogu.
(gdb) bt
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1 0x00007fd34482f8b1 in __GI_abort () at abort.c:79
#2 0x00007fd344e84957 in ?? () from
/usr/lib/x86_64-linux-gnu/libstdc++.so.6
#3 0x00007fd344e8aae6 in ?? () from
/usr/lib/x86_64-linux-gnu/libstdc++.so.6
#4 0x00007fd344e8ab21 in std::terminate() ()
from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#5 0x00007fd344e8ad54 in __cxa_throw ()
from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#6 0x00007fd344e8b2dc in operator new(unsigned long) ()
from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#7 0x00007fd344f1cb8b in std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >::_M_mutate(unsigned long,
unsigned long, char const*, unsigned long) () from
/usr/lib/x86_64-linux-gnu/libstdc++.so.6
#8 0x00007fd344f1e133 in std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >::_M_append(char const*,
unsigned long) ()
from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#9 0x0000000000409df5 in std::operator+<char, std::char_traits<char>,
std::allocator<char> > (__lhs=...,
__rhs=<error: Cannot access memory at address 0x800000007f>)
at /usr/include/c++/7/bits/basic_string.h:5955
#10 0x0000000000408382 in obfuscator::obfuscator (this=0x7ffceddf9690)
at src/obfuscator.hpp:79
#11 0x000000000040786b in main (argc=6, argv=0x7ffceddf9bd8)
---Type <return> to continue, or q <return> to quit---
at src/dirtyphp.cpp:37
 
 
or:
 
 
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1 0x00007fd46f5778b1 in __GI_abort () at abort.c:79
#2 0x00007fd46fbcc957 in ?? () from
/usr/lib/x86_64-linux-gnu/libstdc++.so.6
#3 0x00007fd46fbd2ae6 in ?? () from
/usr/lib/x86_64-linux-gnu/libstdc++.so.6
#4 0x00007fd46fbd2b21 in std::terminate() ()
from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#5 0x00007fd46fbd2d54 in __cxa_throw ()
from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#6 0x00007fd46fbd32dc in operator new(unsigned long) ()
from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#7 0x00007fd46fc64b8b in std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >::_M_mutate(unsigned long,
unsigned long, char const*, unsigned long) () from
/usr/lib/x86_64-linux-gnu/libstdc++.so.6
#8 0x00007fd46fc66133 in std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >::_M_append(char const*,
unsigned long) ()
from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#9 0x0000000000409df5 in std::operator+<char, std::char_traits<char>,
std::allocator<char> > (__lhs=...,
__rhs=<error reading variable: Cannot create a lazy string with
address 0x0, and a non-zero length.>) at
/usr/include/c++/7/bits/basic_string.h:5955
#10 0x0000000000408382 in obfuscator::obfuscator (this=0x7fffba1ac430)
at src/obfuscator.hpp:79
#11 0x000000000040786b in main (argc=6, argv=0x7fffba1ac978)
RM <robert_magdziarz@wp.pl>: Aug 21 10:27AM +0200

>> Anyway, OP would do well to learn to use a debugger to step through
>> the failing constructor, examining variables at the failure point...
 
> Agreed. A nice debugger and the OP's careful eye should help.
 
string strtoupper(string s) {
// convert string to back to upper case
for_each(s.begin(), s.end(), [](char &c) {
c = ::toupper(c);
});
return s;
}
RM <robert_magdziarz@wp.pl>: Aug 21 10:55AM +0200

Sometimes program goes much farther (constructor finishes) and I see:
 
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007f5d376a0df0 in std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >::~basic_string() ()
from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
(gdb) bt
#0 0x00007f5d376a0df0 in std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >::~basic_string() ()
from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#1 0x000000000040a46f in std::_Destroy<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > > (__pointer=0x71)
at /usr/include/c++/7/bits/stl_construct.h:98
#2 0x000000000040a39f in
std::_Destroy_aux<false>::__destroy<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >*> (__first=0x71,
__last=0x4) at /usr/include/c++/7/bits/stl_construct.h:108
#3 0x000000000040a1d2 in std::_Destroy<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >*> (__first=0x71, __last=0x4)
at /usr/include/c++/7/bits/stl_construct.h:137
#4 0x000000000040a0c1 in std::_Destroy<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >*,
std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> > > (__first=0x71, __last=0x4)
at /usr/include/c++/7/bits/stl_construct.h:206
#5 0x00000000004108a8 in std::vector<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >,
std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> > > >::_M_erase_at_end (
this=0x8bdae8, __pos=0x71) at /usr/include/c++/7/bits/stl_vector.h:1518
#6 0x0000000000410816 in std::vector<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >,
std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> > > >::clear (
RM <robert_magdziarz@wp.pl>: Aug 21 11:11AM +0200

Why I have different errors at sequent runs. Program is always run with
same arguments. May there's some problem with compilation?
Here is my Makefile:
 
#ifeq ($(ARCH),win32)
## Windows with the VC++ compiler
#ObjSuf = obj
#SrcSuf = cxx
#ExeSuf = .exe
#DllSuf = dll
#OutPutOpt = -out:
#CXX = cl
#CXXOPT = -O2
#CXXOPT = -Z7
#CXXFLAGS = $(CXXOPT) -G5 -GR -GX -MD -DWIN32 -D_WINDOWS -nologo \
# -DVISUAL_CPLUSPLUS -D_X86_=1 -D_DLL
#LD = link
#LDOPT = -opt:ref
#LDOPT = -debug
#LDFLAGS = $(LDOPT) -pdb:none -nologo
#SOFLAGS = -DLL
 
CXX := -c++ # gcc czy g++?
CXXFLAGS := -Wall -Wextra -Werror -no-pie # -pedantic-errors; add
"-no-pie" to the CMAKE_CXX_FLAGS
LDFLAGS := -L/usr/lib -lstdc++ -lstdc++fs -lm # -Lsrc/boost_1_65_0/lib/
-lboost_regex-gcc34-mt-d-1_3
BUILD := ./build
OBJ_DIR := $(BUILD)/objects
APP_DIR := $(BUILD)/apps
TARGET := dirtyphp
INCLUDE := -Iinclude/ # -I src/boost_1_65_0
SRC := $(wildcard src/*.cpp)
 
OBJECTS := $(SRC:%.cpp=$(OBJ_DIR)/%.o)
 
all: build $(APP_DIR)/$(TARGET)
 
$(OBJ_DIR)/%.o: %.cpp
@mkdir -p $(@D)
$(CXX) $(CXXFLAGS) $(INCLUDE) -c $< -o $@ $(LDFLAGS)
 
$(APP_DIR)/$(TARGET): $(OBJECTS)
@mkdir -p $(@D)
$(CXX) $(CXXFLAGS) -o $(APP_DIR)/$(TARGET) $^ $(LDFLAGS)
 
.PHONY: all build clean debug release
 
build:
@mkdir -p $(APP_DIR)
@mkdir -p $(OBJ_DIR)
 
debug: CXXFLAGS += -DDEBUG -g
debug: all
 
test: CXXFLAGS += -pg # dodałem dynamic execution profiler
test: all
 
release: CXXFLAGS += -O2
release: all # production
 
clean:
-@rm -rvf $(OBJ_DIR)/*
-@rm -rvf $(APP_DIR)/*
RM <robert_magdziarz@wp.pl>: Aug 21 11:25AM +0200

I forgot to tell you one very imortant thing.
Program was running well. Suddenly it started generating core, alghough
I entered no changes to the source code.
Reinstalling compiler doesn't help.
Juha Nieminen <nospam@thanks.invalid>: Aug 21 10:33AM

> identifiers = new strvector[index_what_num];
> random_identifiers = new strvector[index_what_num];
> framework_identifiers = new strvector[index_what_num];
 
If you are just going to ignore all the advice given to you, why are you
even asking here?
 
Your approach at asking here seems to be "how do I get this to compile?"
instead of "how should I implement this properly?"
 
Just because it might compile doesn't mean it's correct. And even if it
appears to work correctly, that doesn't mean it's error-free or implemented
in a proper and advisable way.
 
(For starters, you aren't following the "rule of three" which means your
class will misbehave in certain circumstances. If you followed the
advice given to you of avoiding raw pointers and 'new' and 'delete', that
wouldn't be a problem and you wouldn't need to worry about it. Your code
would also become much simpler and safer.)
Juha Nieminen <nospam@thanks.invalid>: Aug 21 10:35AM

> Program was running well. Suddenly it started generating core, alghough
> I entered no changes to the source code.
> Reinstalling compiler doesn't help.
 
You are not following the advise given to you. You have serious memory
management issues in your code, so it's no wonder it's randomly crashing.
 
Don't use 'new' and 'delete'. Follow the advise given to you.
RM <robert_magdziarz@wp.pl>: Aug 21 02:07PM +0200

W dniu 21.08.2020 o 12:33, Juha Nieminen pisze:
> advice given to you of avoiding raw pointers and 'new' and 'delete', that
> wouldn't be a problem and you wouldn't need to worry about it. Your code
> would also become much simpler and safer.)
 
Sorry.
I repaired my code.
Now it works perfectly!
Problem solved.
Thank you for your answers.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Aug 21 02:53PM +0200

On 21.08.2020 09:48, David Brown wrote:
> first and last (numerically) elements in an enumeration. Other
> languages have it, like Ada's 'First and 'Last attributes, and Pascal's
> "low" and "high" functions.
 
struct Weekdays{ enum Enum: int{
monday, tuesday, wednesday, thursday, friday, saturday, sunday, _
} };
 
template< class Enum_wrapper >
auto n_values() -> int { return Enum_wrapper::_; }
 
Yes?
 
- Alf
Juha Nieminen <nospam@thanks.invalid>: Aug 21 02:28PM

> I repaired my code.
> Now it works perfectly!
 
Pardon me if I remain a bit skeptical, but anyway.
Jorgen Grahn <grahn+nntp@snipabacken.se>: Aug 21 03:07PM

On Fri, 2020-08-21, Alf P. Steinbach wrote:
 
> template< class Enum_wrapper >
> auto n_values() -> int { return Enum_wrapper::_; }
 
> Yes?
 
Surely he meant one you wouldn't have to define yourself; it would
always be there, with the same name and syntax.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
RM <robert_magdziarz@wp.pl>: Aug 21 05:24PM +0200

W dniu 21.08.2020 o 16:28, Juha Nieminen pisze:
>> I repaired my code.
>> Now it works perfectly!
 
> Pardon me if I remain a bit skeptical, but anyway.
 
I tested my PHP obfuscator with two CodeIgniter
projects and it works.
Juha Nieminen <nospam@thanks.invalid>: Aug 21 02:37PM

I have found std::regex to be surprisingly useful and handy
for many situations. Quite often I need to parse some data
from some input, and std::regex can be quite an easy way
to do that in many cases.
 
One thing I have noticed, however, is how astonishingly bit the
class is (or the code that's created when using the class). At
least with gcc on linux (haven't tried with clang).
 
Just using one std::regex and matching a string with it will
increase the size of the produced object file by about 250 kilobytes,
the size of the final executable by about 100 kilobytes (even after
stripping all debug info from it), and increase the compilation time
of that one source file by several seconds (eg. about 2.5 seconds
in this computer I'm using.)
 
It might not sound like much, but when the compilation time of that
source file *without* the std::regex is a tenth of a second,
the resulting object file is like 8 kB and the final executable
(in this case) is about 16 kB, that's quite a huge chunk.
 
Does std::regex really need to be that big? Is there really no way
for them to optimize it to be smaller and faster to compile?
Melzzzzz <Melzzzzz@zzzzz.com>: Aug 21 03:07PM

> (in this case) is about 16 kB, that's quite a huge chunk.
 
> Does std::regex really need to be that big? Is there really no way
> for them to optimize it to be smaller and faster to compile?
I guess that depends on how regex is implemented and that is nowhere
specified...
 
--
current job title: senior software engineer
skills: c++,c,rust,go,nim,haskell...
 
press any key to continue or any other to quit...
U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec
Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi -- Zli Zec
Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi
bili naoruzani. -- Mladen Gogala
Juha Nieminen <nospam@thanks.invalid>: Aug 21 10:39AM

> inline const T& hi() const { return arr[1]; };
> inline T& hi() { return arr[1]; };
> };
 
Those are not returning a reference to a temporary, so they don't have
such an issue.
wyniijj@gmail.com: Aug 21 04:03AM -0700

Juha Nieminen於 2020年8月21日星期五 UTC+8下午6時39分14秒寫道：
> > };
 
> Those are not returning a reference to a temporary, so they don't have
> such an issue.
 
Thanks Jorgen. Problem partially solved, compile time at least. I thought any
user copy assignment operator would disable the default one as the constructor
do! By now, running program compiled with -O2 showed something still not right
Jorgen Grahn <grahn+nntp@snipabacken.se>: Aug 21 11:28AM

> Juha Nieminen於 2020年8月21日星期五 UTC+8下午6時39分14秒寫道：
>> wyniijj@gmail.com wrote:
...
>> Those are not returning a reference to a temporary, so they don't have
>> such an issue.
 
> Thanks Jorgen.
 
You mean Juha, but you are welcome anyway :-)
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
wyniijj@gmail.com: Aug 21 04:32AM -0700

James Kuyper於 2020年8月21日星期五 UTC+8上午4時23分49秒寫道：
 
> > complain others function members. Stll can't replicate the error.
 
> You have still failed to post the program that actually fails. I can
> give you some design advice about this program, but that's about it.
 
Thanks encouraging me to fallback to the very basic steps. I still skipped
too many. The crux: DxInt has several specializations for different types.
In the development, I modified DxInt data member (from two separate half
to one array) by text copy-paste or replacement, causing all the text form
of data members identical. But, forgot the data member of DxInt<uint8_t> is
different from other overloads, causing the bothering temporary object issue.
 
> > //*this=rhs; // gdb halts at this line. seems a recusive call
 
> It certainly is! I'm curious - why didn't you anticipate that it to be
> recursive?
 
Programming is slowly becoming a mechanical thing to me, except dealing with
such kind of low-level problem.
 
James Kuyper <jameskuyper@alumni.caltech.edu>: Aug 21 09:09AM -0400

> James Kuyper於 2020年8月21日星期五 UTC+8上午4時23分49秒寫道：
>> On 8/20/20 3:09 PM, wyniijj@gmail.com wrote:
...
> to one array) by text copy-paste or replacement, causing all the text form
> of data members identical. But, forgot the data member of DxInt<uint8_t> is
> different from other overloads, causing the bothering temporary object issue.
 
Does that mean that you've resolved the problem you were originally
asking about? If not, I recommend doing what you should have done from
the beginning: post code that actually demonstrates the problem you're
running into. Either the actual program that wouldn't compile, or
preferably a simplified version. But NOT a version that has been
simplified to the point that it no longer demonstrates the problem.
 
...
>> recursive?
 
> Programming is slowly becoming a mechanical thing to me, except dealing with
> such kind of low-level problem.
 
I don't quite understand that answer - are you saying that programming
has become so mechanical to you that you've stopped thinking about what
the code you're writing actually means? If that results in you writing
code that is so obviously infinitely recursive without even being aware
of that fact, I recommend reversing that trend.
James Kuyper <jameskuyper@alumni.caltech.edu>: Aug 21 09:27AM -0400


> Thanks Jorgen. Problem partially solved, compile time at least. I thought any
> user copy assignment operator would disable the default one as the constructor
> do! By now, running program compiled with -O2 showed something still not right
 
What does that have to do with your problem? The code above doesn't
involve any copy assignment operators. Other code that was in your
original message, but was clipped above, makes use of assignment
operators. However, it does so only for uint16_t, for which you cannot
provide a user-defined overload.
wyniijj@gmail.com: Aug 21 07:39AM -0700

James Kuyper於 2020年8月21日星期五 UTC+8下午9時28分12秒寫道：
> original message, but was clipped above, makes use of assignment
> operators. However, it does so only for uint16_t, for which you cannot
> provide a user-defined overload.
 
[]$ g++ test2.cpp -std=c++11 -Wall -Wextra -pedantic
test2.cpp: In copy constructor 'DxInt<unsigned int>::DxInt(const DxInt<unsigned int>&)':
test2.cpp:16:35: warning: implicitly-declared 'DxInt<unsigned int>& DxInt<unsigned int>::operator=(const DxInt<unsigned int>&)' is deprecated [-Wdeprecated-copy]
16 | DxInt(const DxInt& s) { *this=s; };
| ^
test2.cpp:16:5: note: because 'DxInt<unsigned int>' has user-provided 'DxInt<unsigned int>::DxInt(const DxInt<unsigned int>&)'
16 | DxInt(const DxInt& s) { *this=s; };
| ^~~~~
test2.cpp: At global scope:
test2.cpp:53:2: warning: extra ';' [-Wpedantic]
53 | };
| ^
 
//------------------------------------
Compiling with option -std=c++11 -Wall -Wextra -pedantic, showed the "implicitly-declared (operator=) is deprecated
 
I don't know why the default operator= can be be deprecated. However the
diagnosis message reminds me of lack of operator=(DxInt<T>&)
wyniijj@gmail.com: Aug 21 07:41AM -0700

Jorgen Grahn於 2020年8月21日星期五 UTC+8下午7時28分27秒寫道：
 
> --
> // Jorgen Grahn <grahn@ Oo o. . .
> \X/ snipabacken.se> O o .
 
Sorry, that's embarrassing, Juha
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)